Thanks Johan,
I did not set out to enhance the online documentation per se, as am I trying
to learn from it, making refinements where necessary, so other users
consuming the same information would have a stronger footing.
My general feeling about Apache CXF is that it has a strong vibrant
community and that the project is very well matured.
Due to the recurrent nature of similar comments I'm getting on my updates,
I'm just going to tread a little more lightly with any future updates I may
make... as the comments made by the CXF folks to me, do make sense.
-- Robert
-----Original Message-----
From: Johan Edstrom
Sent: Thursday, November 11, 2010 11:25 AM
To: [email protected]
Subject: Re: Apache CXF tooling usage definitions
Robert,
This is open source, debate and disagreement is part of the deal -
I think you have done a ton of good things, that everything you do isn't
praised and
sometimes is "shot down", that is just part of the fun.
I certainly hope that you don't see one comment (that I thought was
constructive) as
a signal to community disagreement.
just my 0.2.
/je
On Nov 11, 2010, at 9:20 AM, Robert Liguori wrote:
Glen, Benson, and Apache CXF team,
Here are my responses to Glen's comments/observations related to my
contributions.
Glen's comment: "But, also, as for the issue of time you mention, this
brings up an earlier
concern I had about the expansive "thank you" page you recently made
(http://cxf.apache.org/special-thanks.html), in which you list and explain
every Apache and other project that CXF imports, as well as (IMO)
erroneously list Apache-wide helpers like Atlassian that should be thanked
at an Apache-level and not individually within every project. "
Robert Response: I returned the "thank you" page to the version it was at
before I touched it. I also returned the "Architecture Guide" page to the
original version, as I had left it in a flux state and do not plan or have
the experience to finish it in the proper manner.
Glen's comment: "One should also analyze the opportunity cost of making
the command line
options looking the same as the GNU conventions compared to adding
additional functionality to CXF,..."
Robert's Response: The definitions of the command line options are
different in at least three different places. Some of the inline usage
definitions don't even match what the tool actually does. For the most
extreme example, the usage for "idl2wsdl", starts out with "idltowsdl";
just do a "idl2wsdl -help" to see for yourself. "Cleanup" was my intent
of the issue raised, meeting conventions in the process is considered a
"best practice" and would be nice to the end-user community if achieved.
Glen's comment: "... a similar issue to your earlier desire to have the
CXF website be reformatted to look like Camel, ServiceMix, and
ActiveMQ's."
Robert's Response: It was my general feeling that ASF projects should be
branded in a similar fashion. However, it's been made to clear to me by
several people at ASF that forcing branding does not work well with
open-source.
Glen's comment: "So as you enhance the CXF documentation, please be sure
that you're not
giving CXF "puppies as presents", things that look cute but are of
relatively limited benefit and need a lot of maintenance afterwards to
remain cute. "
Robert's Response: I'm definitely not on the same page as the CXF team.
It was a nice stay. If any of my other updates seem that they do more
harm than good, please revert the web pages back to old instances. I'm
not going to fall anything else back, as I feel that has been value in my
improvements to the web-pages content.
To wrap things up on my side, I'll look at the issues I have opened and
will try to align them with the general open-source philosophy.
Take care,
Robert
-----Original Message----- From: Glen Mazza
Sent: Thursday, November 11, 2010 10:30 AM
To: [email protected]
Subject: Re: Apache CXF tooling usage definitions
Robert Liguori wrote:
Note that I personally don't have time to contribute to this, but I do
think
that refined, synchronized and more accurate usage definitions would
bring
enhanced 'polished' value to the product.
Several of your suggestions Robert would seem better suited for the
CXF-Dev
rather than the CXF-User's list. For any project, not just CXF, many
ideas
look excellent at first glance but for various reasons are known not to be
such a great idea by developers and close observers who have spent years
with the project. However unfair given all your work on the
documentation,
heavy usage of CXF-Users over CXF-Dev can give the impression that you
realize that a lot of your ideas hold less and less water the more
experienced one is with the project and that you are using the User
community to unduly push sweet-looking-on-the-surface changes that perhaps
should not be made.
One should also analyze the opportunity cost of making the command line
options looking the same as the GNU conventions compared to adding
additional functionality to CXF, a similar issue to your earlier desire to
have the CXF website be reformatted to look like Camel, ServiceMix, and
ActiveMQ's. Another factor is that volunteer developers need to work on
tasks that further themselves first and busywork (or "polishing") rarely
accomplishes that. For open source to be successful, a volunteer
developer
should always be *stronger* as a result of volunteering on an open source
project, not weaker.
But, also, as for the issue of time you mention, this brings up an earlier
concern I had about the expansive "thank you" page you recently made
(http://cxf.apache.org/special-thanks.html), in which you list and explain
every Apache and other project that CXF imports, as well as (IMO)
erroneously list Apache-wide helpers like Atlassian that should be thanked
at an Apache-level and not individually within every project. No
question,
it looks very nice and professional now, but who's going to be maintaining
this? It's like you're giving us a new puppy as a present. This page is
not going to be looking very nice in several months once it falls out of
date, links get old, etc. It's not necessary for an Apache project to
have
to individually thank every other Apache project it incorporates. The
source of record for determining the dependencies used by CXF is always
going to be its POM files or the lib folder of its distribution, not a
website page.
So as you enhance the CXF documentation, please be sure that you're not
giving CXF "puppies as presents", things that look cute but are of
relatively limited benefit and need a lot of maintenance afterwards to
remain cute.
Thanks,
Glen
--
View this message in context:
http://cxf.547215.n5.nabble.com/Apache-CXF-tooling-usage-definitions-tp3253466p3260484.html
Sent from the cxf-user mailing list archive at Nabble.com.
