Glen Mazza wrote:
Please do not run back to FOP. We need more committers to be actively involvedThanks Craig, for your detailed response--I had to read it twice to fully absorb it! From the perspective of my concerns, you clearly found my cynicism unwarranted (to say the least). FWIW, my -1 is now a +1.
Also, it is evident that many of my remarks on BEA and its XMLBeans product were painfully classless and fourth-rate--for those who are or were affiliated with XMLBeans--please excuse my comments, they weren't justified given both what I knew and now know about the product.
<red face/> With tail well between my legs, I'm now
going to run back to the FOP project...
with the whole project. I appreciate the effort that you made to express you concerns
and do something about them instead of saying, "Aw, who cares". So please stick around
here in [EMAIL PROTECTED] We're all learning here.
What Craig is doing here is what is expected of all committers and membersForwarding, Craig McClanahan wrote: ---------------------------------------------------
Glen (and others -- presumably someone will moderate this on to [EMAIL PROTECTED] for me),
Thanks for the vote of confidence in my opinions :-). Although, I have to confess I'm by no means an expert
in XML technologies, I'm fair-to-middlen
at Java code, and I'm definitely a customer of XML
technologies of various types (most heavily focused on
reading configuration files in things like
Tomcat and Struts, less so on rendering XML output).
My comments will be mostly philosophical in nature,
because I have not done any large scale investigation
of XmlBeans as a technology; I've just played with the
examples and thought about how it could be used. It's
pretty intruiging, and I'll comment on that -- but I'd
also like to throw a couple of comments in on the
decision process of how we at Apache accept
projects, and why we might want to or not want to
accept it, or any other project. As such, I'm
speaking in my "member of the Apache Software
Foundation" and "member of the Jakarta PMC" hats.
of ASF projects: He is looking out for the interests of the ASF and the larger
Java community as a whole.
But, even if your presumptions about BEA's motivations
were accurate (and I certainly don't get that impression from what I've seen so far), is that relevant to a decision on whether Apache should accept this technology? Personally, I don't think so -- what's important to me is that we be willing to host projects of "interesting" software that can attract a community of developers. Beyond interesting to developers, I also believe that Apache software should be interesting to users. (The thing that makes me the most proud about Struts, for example, is the user community, not the quality of the code, which is high, or even the really great group of committers that have come together to make it so.)
The more important issues you raise, though, are really the two things that you mention in the middle paragraph:
* The implied presumption that "XML and XSLT are too
difficult to use and must be masked." (As a consumer
of XML technologies, I must admit that I agree with
this premise.)
I do too, and the last few years of consulting with businesses has only reinforced my belief.
Code bases without a healthy developer community are *worthless*.* The idea that different approaches to dealing with these technologies "may not be compatible with what XML-Apache is trying to accomplish."
The second issue (conflict with other projects) speaks
more to the Apache community's purposes of providing
high quality software with active developer
communities. At least over in Jakarta (which, after
all, now hosts three high quality web application
frameworks: Struts, Tapestry, and Turbine), we have
not considered alternate solutions in the same
problem space to be a fatal flaw. You'll see the same
philosophy present in Jakarta Commons -- there isn't
always "one right answer" to every single problem. Yes, groups are encouraged to work together instead of
separately (and all three of these frameworks are
already sharing fundamental pieces like the file
upload package from Commons). In the case of
XmlBeans, how you guys finally want to organize things
(i.e. whether it gets absorbed into some existing
xml.apache.org project that expands scope, or whether
it stays separate) doesn't matter -- whether the
technology itself is compelling and useful, AND can
attract an Apache style developer community, is more
important IMHO.
As I said, though, I'm not all that familiar with theWe've had some internal competition that many of us (including me) would like to
feelings toward community and internal competition on
the XML side of the house. I probably should be, so
this exercise is useful to me as a learning experience
in addition to whatever advice I can offer on the
particular subject at hand.
forget (the whole Xerces / Crimson thing), and I think that bad experience has made
us competition averse. This is a bad thing. There is competition in the marketplace
of ideas and pretending that other people won't have a better idea and blow away
one of our projects just doesn't make sense. It makes much more sense to have
those smart people come here and have us all collaborate together.
* I don't doubt that there are alternative approaches+1
already in existence, both at xml.apache.org and
jakarta.apache.org. I would encourage you NOT to
consider that an automatic reason to vote against. Diversity, cross-fertililzation of ideas, and (yes)
even a degree of "competition" can lead to better
projects. So can collaboration in an expanded project
that might grow to a larger scope than it currently
occupies, if that makes sense (that's for you guys to
decide as part of the incubation process, if XmlBeans
is accepted).
* In earlier discussions (at least the ones I saw onPeople need to be aware that XMLBeans or any other project, won't be fully
the Jakarta General and community lists), there were
concerns about licensing and the relative number of
committers from BEA versus other organizations. Those
sound like they are either resolved or will have the
opportunity to be resolved in the incubator.
accepted until the incubator says ok. I think that we are probably on the
way to having this happen. They already have 3 non BEA committers and if
both Steven and I earn commit privs that would bring the total to 5 / 11, leaving
us 1 person away from 50%, which would pass the Andy Oliver threshhold.
* My only concern about XmlBeans, quite frankly, is
one that you did not raise directly -- in the Java
space there is a standard API for binding XML to Java
objects (JAXB), and XmlBeans is not an implementation
of that standard. That's not necessarily a fatal flaw
(after all, my favorite webapp framework is not a
standard either, although it is being impacted by the
ones I deal with in my "day job" -- Servlet, JSP,
JSTL, and JavaServer Faces), but it is a consideration
to think about. Indeed, considering some of the loud
voices at Apache, and their opinions on Java standards
and the JCP, this might well be a positive :-). But
it should be factored in to thinking about the effort
that will be acquired to attract and maintain a
developer community, and a user community, should
XmlBeans be accepted. The XML community already has
examples of both communities that implement standard
APIs, and those who are innovating on their own.
I refer you to the roadmap for XML Beans that Cliff Schimdt provided http://nagoya.apache.org/wiki/apachewiki.cgi?XmlBeansRoadMap which includes JSR-31 compatibility if the community deems that interesting enough to provide. So I think we are covered there.
Bravo Craig for taking the time to write such a great post!
Let me also give a brief XMLBeans status update. I was at OSCON last
week in Portland, and the XMLBeans guys from BEA were also there, so
we had lunch in the park one afternoon and talked about what it means to be
an Apache project, how the projects work, and did some q&a. These folks
want to do open source, and they seem very willing to learn to do that in the
Apache way. The incubator will give them the opportunity to prove that out.
This is a sharp team that is already working in a geographically distributed
situation. I think/hope that things are going to work out well here. I'd encourage
anyone who has concerns about the community aspects to watch the incubation
process like a hawk.
Ted
--------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
