I do think that pushing a JSR for Wicket will have a negative influence
on the spirit of Wicket and it's community due to the politics involved
with a JSR. Politics are so not the Wicket way. This is what I mean with
the "wrong way" and yes, that is mighty subjective.
I also expect there will not be enough support from other parties to
participate in a JSR (again, highly subjective), because there is
nothing for them to gain. Which I believe is one of your main arguments:
there will not be a broader input base. But I think Wicket receives
enough input since the Wicket developers see what is happening in other
projects around them and they take that with them.
And without enough support, the JSR will be dropped and I think that in
the corporate eye, Wicket will turn into 'that project that didn't make
the JSR', and wide adoption will be even further away.
But again, without a concrete proposal, I have no idea what the
specification request would describe and what the scope of such a JSR
would be. Could you elaborate on that? Maybe that clears things up for me.
BTW, I think not that Hibernate has grown as a result of the
JPA-standard, but that the Java EE standard has grown a a result of the
emerging of ORM-tools (like Hibernate, Toplink etc.) and other popular
application stacks, like Spring etc. The quality of Hibernate would have
increased without the JPA-spec anyway (and ofcourse, there was - and
there still is - enough opportunity to improve).
Hoover, William wrote:
I agree that we need to change the views of corporate managers in the
"right way" by illustrating the cost savings achieved though a reduction
in development time. At the same time, I don't believe that this will
change the Wicket community in the "wrong way" (which is a highly
subjective statement). I'm only presenting the alternative viewpoint. It
is possible that a standard could potentially inhibit progression due to
contrasting viewpoints within the community, but it is also equally
possible that it could lead to a value-added aspect by introducing a
broader input base to the Wicket community that could speed progression
(Hibernate/JPA is an example of this). There is always a possibility
that progress can be slowed as the number of members increase because
there are more viewpoints to be examined/debated. I think that there is
a higher probability that the community will grow if such a standard
were to be adopted.
Just because there is already a specification for a "web framework"
(JSF) that does not constitute abandoning a standard approach. Look at
JAX-WS vs JAX-RS. They accomplish many of the same objectives, but they
both are part of the proposed profile stack
(http://www.theserverside.com/tt/articles/article.tss?l=JavaEE6Overview)
. A Wicket implementation could orchestrate a refreshing alternative
approach to JSF in the same manner that it does today.
When I referred to open-mindedness I was referring to being open-minded
to the ideas behind the push... I didn't necessary intended to imply
that anyone would not be open-minded if they did not support a JSR :o)
-----Original Message-----
From: Dave Schoorl [mailto:mailli...@cyber-d.com]
Sent: Friday, February 13, 2009 9:21 AM
To: users@wicket.apache.org
Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam
I am not sure what you would like to standardize. Given your JPA
example, I would guess that you want to push a JSR for a web framework
or something. But there is already something like that: JSF. Just let
Wicket be Wicket and instead of changing Wicket (and it's community) in
the wrong way, let's try to change the views of corporate managers in
the right way. As Thomas said earlier "What we need is less talks titled
'why wicket is cool' and more 'cut your development costs in two with
Wicket' ".
And I do not think that the lack of support for pushing a JSR has
anything to do with a lack of open-mindedness...
Hoover, William wrote:
I hear the arguments and I completely agree with the notion that
innovation usually happens "elsewhere" and a JSR/JCP would slow that
process down. I just want to objectively view the other side of the
spectrum :o)
From a developers point-of-view standardization can often be a thorn
in our side, but for management it can offer a
vendor-independent/implementation-independent solution.
Maintaining/upgrading infrastructure is difficult, expensive and time
consuming. From the point-of-view of management a standard can often
minimize the risk of vender lock-in.
Another thing to consider is that a broader multi-community
involvement could also bread innovation. There may be other innovators
from other communities that may have valuable input that could improve
Wicket in ways that may have not been previously considered. IMHO, the
biggest argument for JSR/JCP is that there is often a broader
involvement in the process. Hibernate, for instance, was in a similar
position a few years back when they introduced a new persistence
concept. They have since become heavily involved in the JPA
specification process. When I first worked with Hibernate, like many, I
was very impressed (similar to the first time I worked with Wicket :o),
but looking back at how Hiberante initially did things to how they do
them now there are some huge improvements due to the JPA specification.
My hope is that the Wicket community can be as open-minded to this
notion as they are to the open source code they represent :o)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
