RE: Wicket at ApacheCon EU'09 in Amsterdam
That is a good point... That is the very reason why they are now trying to push WebBeans as part of the standard profile ;o) -Original Message- From: Oleg Taranenko [mailto:taranenko.for...@googlemail.com] Sent: Friday, February 13, 2009 4:05 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam Hmm... some time ago (approx 1,5 year ) was attempts to marry JBoss Seam and Wicket. Was it successful? May be this is an example, why wicket should to be treated as a standard? Oleg On Fri, Feb 13, 2009 at 4:59 PM, Hoover, William whoo...@nemours.orgwrote: First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam 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. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? 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. look hibernate is an implementation of a persistence.. And they adapted (and where involved) into the specifications yes Ok now translate that to wicket.. What is wicket an implementation of? a webframework? ahh.. tapestry is also a webframework and struts is also a webframework They all implement the standard webframework spec.. which is the servlet spec.. So JPA Spec == Servlet Spec Hibernate == Wicket TopLink == Tapestry So wicket is already in the JSR/JCP ! we are an enhancement/implementation of the servlet spec :) ok ok. Maybe you say.. sevlet spec implementation == servlet .jar and tomcat ;) not the thing you would build on top of that again But then if you have wicket,tapestry and struts (and x and y) and then you want to define a Web Framework spec that all of them can adapt to what would that then be? What would that then gain? Would that mean that tapestry components/pages could run inside wicket? It is just not as easy to do as with a persistence spec. Which is pretty easy
RE: Wicket at ApacheCon EU'09 in Amsterdam
http://opensource.atlassian.com/confluence/spring/display/JSR168/2008/04 /18/Plans+for+JSR+286+Support -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, February 13, 2009 4:15 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam how will having wicket as a standard help this? look at spring, it is no jsr but a lot of projects integrate with it, and it in return integrates with other projects. anyways, there is already a start of wicket seam support by the seam folks. http://in.relation.to/Bloggers/SeamlessWicket -igor On Fri, Feb 13, 2009 at 1:05 PM, Oleg Taranenko taranenko.for...@googlemail.com wrote: Hmm... some time ago (approx 1,5 year ) was attempts to marry JBoss Seam and Wicket. Was it successful? May be this is an example, why wicket should to be treated as a standard? Oleg On Fri, Feb 13, 2009 at 4:59 PM, Hoover, William whoo...@nemours.orgwrote: First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam 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. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? 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. look hibernate is an implementation of a persistence.. And they adapted (and where involved) into the specifications yes Ok now translate that to wicket.. What is wicket an implementation of? a webframework? ahh.. tapestry is also a webframework and struts is also a webframework They all implement the standard webframework spec.. which is the servlet spec.. So JPA Spec == Servlet Spec Hibernate == Wicket TopLink == Tapestry So wicket is already in the JSR/JCP ! we are an enhancement/implementation of the servlet spec :) ok ok. Maybe you say.. sevlet spec implementation == servlet .jar and tomcat ;) not the thing you would build on top
RE: Wicket at ApacheCon EU'09 in Amsterdam
As the programmer currently maintaining/improving the seam/wicket integration: (a) I recently got a change to wicket from Igor in less than a day, upon request, to support this integration. I doubt I would have had as much luck if the behavior of wicket was in a JSR, but in any case, the lack of a JSR didn't hinder me. (b) I've coded things to JSR specs before, and found it no easier (and often less) than reading wicket's source, which is very well commented, and asking questions. The ability to target a technology for integration is not about whether it's standardized. (c) I won't comment on the why of Seam turning into WebBeans using JSR, but having been on the WebBeans mailing list for a while, I don't think I would ever volunteer to shepherd anything through that process. It was dreadful, slow, and a lot of compromises were made that IMHO had no technical merit and were completely politically motivated. -Clint whoover wrote: That is a good point... That is the very reason why they are now trying to push WebBeans as part of the standard profile ;o) -Original Message- From: Oleg Taranenko [mailto:taranenko.for...@googlemail.com] Sent: Friday, February 13, 2009 4:05 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam Hmm... some time ago (approx 1,5 year ) was attempts to marry JBoss Seam and Wicket. Was it successful? May be this is an example, why wicket should to be treated as a standard? Oleg On Fri, Feb 13, 2009 at 4:59 PM, Hoover, William whoo...@nemours.orgwrote: First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam 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. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? 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. look hibernate is an implementation of a persistence
RE: Wicket at ApacheCon EU'09 in Amsterdam
Rod Johnson (creator of spring) talks about JCP, JEE, and Spring: http://java.sys-con.com/node/732455 -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, February 13, 2009 4:15 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam how will having wicket as a standard help this? look at spring, it is no jsr but a lot of projects integrate with it, and it in return integrates with other projects. anyways, there is already a start of wicket seam support by the seam folks. http://in.relation.to/Bloggers/SeamlessWicket -igor On Fri, Feb 13, 2009 at 1:05 PM, Oleg Taranenko taranenko.for...@googlemail.com wrote: Hmm... some time ago (approx 1,5 year ) was attempts to marry JBoss Seam and Wicket. Was it successful? May be this is an example, why wicket should to be treated as a standard? Oleg On Fri, Feb 13, 2009 at 4:59 PM, Hoover, William whoo...@nemours.orgwrote: First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam 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. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? 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. look hibernate is an implementation of a persistence.. And they adapted (and where involved) into the specifications yes Ok now translate that to wicket.. What is wicket an implementation of? a webframework? ahh.. tapestry is also a webframework and struts is also a webframework They all implement the standard webframework spec.. which is the servlet spec.. So JPA Spec == Servlet Spec Hibernate == Wicket TopLink == Tapestry So wicket is already in the JSR/JCP ! we are an enhancement/implementation of the servlet spec :) ok ok. Maybe you say.. sevlet spec implementation == servlet .jar and tomcat ;) not the thing you would build on top
Re: Wicket at ApacheCon EU'09 in Amsterdam
Bill Joy from Sun once said: innovation happens elsewhere. I think that the where elsewhere isn't, it is the JCP. Standardization is just antithetical to innovation. Once something is fixed in brick/mortar how can you innovate? Wicket is very comfortably located elsewhere. Martijn On Thu, Feb 12, 2009 at 10:05 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: we like the agility that the independence from any sort of a standard offers us. -igor On Thu, Feb 12, 2009 at 12:01 PM, Hoover, William whoo...@nemours.org wrote: Judging by the responses (or the lack thereof), It seems as though there isn't enough support from the Wicket community to push for something like this :( -Original Message- From: tomlist0...@gmail.com [mailto:tomlist0...@gmail.com] On Behalf Of Thomas Mäder Sent: Thursday, February 12, 2009 12:57 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide). The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled why wicket is cool and more cut your development costs in two with Wicket. From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts). Thomas On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner jcompag...@gmail.comwrote: And then come into the horrible voting/administive stuff? Long Release cycles that are controlled, features that are discussed over and over. Hmm On 12/02/2009, Hoover, William whoo...@nemours.org wrote: Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, February 11, 2009 5:33 PM To: users@wicket.apache.org Subject: Wicket at ApacheCon EU'09 in Amsterdam We're happy to announce a lot of Wicket involvement at the upcoming ApacheCon in Amsterdam (23-27 March 2009) First of all we have 2 training sessions available: - Introduction to Wicket by Martijn Dashorst on Mon 23 March (http://tinyurl.com/aceu09wicket1) - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2) Both courses are hosted by core members. Martijn has co-authored Wicket in Action and Timo has been involved with WicketTester and JDave. There is no better team to get you and your team up to speed with the finest Java web framework available and start cranking out fully tested applications. Martijn will also present Wicket in Action during the normal conference days. A quick introduction to Wicket's core features in just one hour. But attending the conference will give you much more: over 60 sessions covering your favorite Apache projects. Amsterdam is great, but Wicket meetups in Amsterdam are even better! We're attempting to schedule a Wicket meetup during the conference at the conference floor. Details will follow soon. Read more about ApacheCon EU 2009 here: http://www.eu.apachecon.com/c/aceu2009/ See you in Amsterdam! Martijn - 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 -- Thomas Mäder Wicket Eclipse Consulting www.devotek-it.ch - 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 -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3
Re: Wicket at ApacheCon EU'09 in Amsterdam
and what would a wicket standard give you? Except that those idiotic managers then say its standardized.. now you can use it why is that is a standard for ever? dont think so everything dies. But would it run on more platforms? Would we have multiply implementations? Because thats most of the time a JCP/JSR does, it doesnt have an implementation, what wicket is, but a description/interfaces what an implementation should do.. johan On Fri, Feb 13, 2009 at 10:00, Martijn Dashorst martijn.dasho...@gmail.comwrote: Bill Joy from Sun once said: innovation happens elsewhere. I think that the where elsewhere isn't, it is the JCP. Standardization is just antithetical to innovation. Once something is fixed in brick/mortar how can you innovate? Wicket is very comfortably located elsewhere. Martijn On Thu, Feb 12, 2009 at 10:05 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: we like the agility that the independence from any sort of a standard offers us. -igor On Thu, Feb 12, 2009 at 12:01 PM, Hoover, William whoo...@nemours.org wrote: Judging by the responses (or the lack thereof), It seems as though there isn't enough support from the Wicket community to push for something like this :( -Original Message- From: tomlist0...@gmail.com [mailto:tomlist0...@gmail.com] On Behalf Of Thomas Mäder Sent: Thursday, February 12, 2009 12:57 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide). The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled why wicket is cool and more cut your development costs in two with Wicket. From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts). Thomas On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner jcompag...@gmail.com wrote: And then come into the horrible voting/administive stuff? Long Release cycles that are controlled, features that are discussed over and over. Hmm On 12/02/2009, Hoover, William whoo...@nemours.org wrote: Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, February 11, 2009 5:33 PM To: users@wicket.apache.org Subject: Wicket at ApacheCon EU'09 in Amsterdam We're happy to announce a lot of Wicket involvement at the upcoming ApacheCon in Amsterdam (23-27 March 2009) First of all we have 2 training sessions available: - Introduction to Wicket by Martijn Dashorst on Mon 23 March (http://tinyurl.com/aceu09wicket1) - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2) Both courses are hosted by core members. Martijn has co-authored Wicket in Action and Timo has been involved with WicketTester and JDave. There is no better team to get you and your team up to speed with the finest Java web framework available and start cranking out fully tested applications. Martijn will also present Wicket in Action during the normal conference days. A quick introduction to Wicket's core features in just one hour. But attending the conference will give you much more: over 60 sessions covering your favorite Apache projects. Amsterdam is great, but Wicket meetups in Amsterdam are even better! We're attempting to schedule a Wicket meetup during the conference at the conference floor. Details will follow soon. Read more about ApacheCon EU 2009 here: http://www.eu.apachecon.com/c/aceu2009/ See you in Amsterdam! Martijn - 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 -- Thomas Mäder Wicket Eclipse Consulting www.devotek-it.ch
Re: Wicket at ApacheCon EU'09 in Amsterdam
Hi all I'm new to this list (and Wicket), and was interested in this discussion. On 12/02/2009, at 11:32 PM, Hoover, William wrote: Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) It might be interesting to examine this idea in the context of OSGi. OSGi is a standard for componentisation and packaging and component lifecycle management that has it roots in embedded devices, and incorporates a whole range of further standards related to this type of platform. It grew out of efforts that were mostly independent of Sun, and has continued to evolve as a standard in a separate organisation to the JSR process. It now has a JSR (277), but the OSGi specifications evolve separately of this original JSR. It has multiple implementations (Felix, Equinox, Knopflerfish, etc). Its flexibility in its design (extender bundles, manifest extensions, whiteboard model, etc assist this) has led to many addons that build upon it such as Spring DM, iPOJO, etc. In the next version of the specification many of these community ideas will be incorporated back into the main specifications. The Core OSGi specification doesn't add much to the language, but its Compedium specifications, which build upon the Core spec, provide everything from configuration management, device resolution, to user administration and logging. Sun were looking at using it in Java 7 in order to modularise the JVM, a similar goal to the Apache Harmony project IIRC. They have since dropped this goal and have revived JSR 294 for modularisation. OSGi continues to move along alone and gain its own popularity without the JSR/JCP process. Sun's attitude seems to be to just ignore OSGi (a form of NIH syndrome?). IMHO what this means for Wicket is: unless it provides a small base for lots of extra functionality to be built upon, its just going to get mired in the politics of the JSR/JCP process and not really achieve anything. It will probably end up being shunned as a competitor to JSF and left unresolved. It may be better for Wicket to look at managing its own APIs so there is less breakage between versions (note: I've only begun using Wicket recently so I'm not trying to suggest this is the case) and that versions are clearly delineated in terms of API compatibility between them. It could try and elevate the Wicket extensions to be more tightly managed within the Wicket project, and seek from time to time to incorporate these back in into the Wicket mainline. In this way, Wicket becomes standardised but still maintains the freedom to innovate more quickly. Wicket seems to be tightly modularised enough (or able to modularised) that using Wicket as a base to grow new and interesting functionality whilst maintaining a stable core seems feasible. Cheers Chris --- Christopher Armstrong carmstrong at fastmail com au. Christopher Armstrong carmstr...@fastmail.com.au - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket at ApacheCon EU'09 in Amsterdam
totally against pushing wicket as a standard / jsr. it has already been stated by some of you, but i'd like to highlight the fact that bureaucracy goes against flexibility. instead of having wicket to change to please management, why don't we push to have more managers that think out-of-the-box and choose wicket for its actual strengths rather than because it wears a jcp badge? francisco -- http://wickethub.org On Fri, Feb 13, 2009 at 10:10 AM, Johan Compagner jcompag...@gmail.com wrote: and what would a wicket standard give you? Except that those idiotic managers then say its standardized.. now you can use it why is that is a standard for ever? dont think so everything dies. But would it run on more platforms? Would we have multiply implementations? Because thats most of the time a JCP/JSR does, it doesnt have an implementation, what wicket is, but a description/interfaces what an implementation should do.. johan On Fri, Feb 13, 2009 at 10:00, Martijn Dashorst martijn.dasho...@gmail.comwrote: Bill Joy from Sun once said: innovation happens elsewhere. I think that the where elsewhere isn't, it is the JCP. Standardization is just antithetical to innovation. Once something is fixed in brick/mortar how can you innovate? Wicket is very comfortably located elsewhere. Martijn On Thu, Feb 12, 2009 at 10:05 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: we like the agility that the independence from any sort of a standard offers us. -igor On Thu, Feb 12, 2009 at 12:01 PM, Hoover, William whoo...@nemours.org wrote: Judging by the responses (or the lack thereof), It seems as though there isn't enough support from the Wicket community to push for something like this :( -Original Message- From: tomlist0...@gmail.com [mailto:tomlist0...@gmail.com] On Behalf Of Thomas Mäder Sent: Thursday, February 12, 2009 12:57 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide). The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled why wicket is cool and more cut your development costs in two with Wicket. From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts). Thomas On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner jcompag...@gmail.com wrote: And then come into the horrible voting/administive stuff? Long Release cycles that are controlled, features that are discussed over and over. Hmm On 12/02/2009, Hoover, William whoo...@nemours.org wrote: Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, February 11, 2009 5:33 PM To: users@wicket.apache.org Subject: Wicket at ApacheCon EU'09 in Amsterdam We're happy to announce a lot of Wicket involvement at the upcoming ApacheCon in Amsterdam (23-27 March 2009) First of all we have 2 training sessions available: - Introduction to Wicket by Martijn Dashorst on Mon 23 March (http://tinyurl.com/aceu09wicket1) - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2) Both courses are hosted by core members. Martijn has co-authored Wicket in Action and Timo has been involved with WicketTester and JDave. There is no better team to get you and your team up to speed with the finest Java web framework available and start cranking out fully tested applications. Martijn will also present Wicket in Action during the normal conference days. A quick introduction to Wicket's core features in just one hour. But attending the conference will give you much more: over 60 sessions covering your favorite Apache projects. Amsterdam is great, but Wicket meetups in Amsterdam are even better! We're attempting to schedule a Wicket meetup during the conference at the conference floor. Details will follow soon. Read more about ApacheCon EU 2009 here: http://www.eu.apachecon.com/c/aceu2009/ See you in Amsterdam! Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket at ApacheCon EU'09 in Amsterdam
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) -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 4:10 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam and what would a wicket standard give you? Except that those idiotic managers then say its standardized.. now you can use it why is that is a standard for ever? dont think so everything dies. But would it run on more platforms? Would we have multiply implementations? Because thats most of the time a JCP/JSR does, it doesnt have an implementation, what wicket is, but a description/interfaces what an implementation should do.. johan On Fri, Feb 13, 2009 at 10:00, Martijn Dashorst martijn.dasho...@gmail.comwrote: Bill Joy from Sun once said: innovation happens elsewhere. I think that the where elsewhere isn't, it is the JCP. Standardization is just antithetical to innovation. Once something is fixed in brick/mortar how can you innovate? Wicket is very comfortably located elsewhere. Martijn On Thu, Feb 12, 2009 at 10:05 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: we like the agility that the independence from any sort of a standard offers us. -igor On Thu, Feb 12, 2009 at 12:01 PM, Hoover, William whoo...@nemours.org wrote: Judging by the responses (or the lack thereof), It seems as though there isn't enough support from the Wicket community to push for something like this :( -Original Message- From: tomlist0...@gmail.com [mailto:tomlist0...@gmail.com] On Behalf Of Thomas Mäder Sent: Thursday, February 12, 2009 12:57 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide). The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled why wicket is cool and more cut your development costs in two with Wicket. From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts). Thomas On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner jcompag...@gmail.com wrote: And then come into the horrible voting/administive stuff? Long Release cycles that are controlled, features that are discussed over and over. Hmm On 12/02/2009, Hoover, William whoo...@nemours.org wrote: Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, February 11, 2009 5:33 PM To: users@wicket.apache.org Subject: Wicket at ApacheCon EU'09 in Amsterdam We're happy to announce a lot of Wicket involvement at the upcoming ApacheCon in Amsterdam (23-27 March 2009) First of all we have 2 training sessions available: - Introduction to Wicket by Martijn Dashorst on Mon 23 March (http://tinyurl.com
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
Re: Wicket at ApacheCon EU'09 in Amsterdam
this has nothing to do with being open-minded. i'm pretty sure that most non-trivial projects out there using jpa with hibernate implementation can go through a big pain if they ever decide to change jpa vendor. now that you talk about jpa, this is an example of how backward a spec can be: jpa 2.0 draft is only now addressing criteria, when we should be including statically-typed queries and so on (ala linq / quaere / jaqu). granted the process might bring some benefit to wicket, but there are way too many disadvantages, imo. and i don't really see how wicket could become a sort of standard that gets different implementations. anyway, i think we've got waaay out of topic =) francisco -- http://wickethub.org On Fri, Feb 13, 2009 at 2:36 PM, Hoover, William whoo...@nemours.org 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) -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 4:10 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam and what would a wicket standard give you? Except that those idiotic managers then say its standardized.. now you can use it why is that is a standard for ever? dont think so everything dies. But would it run on more platforms? Would we have multiply implementations? Because thats most of the time a JCP/JSR does, it doesnt have an implementation, what wicket is, but a description/interfaces what an implementation should do.. johan On Fri, Feb 13, 2009 at 10:00, Martijn Dashorst martijn.dasho...@gmail.comwrote: Bill Joy from Sun once said: innovation happens elsewhere. I think that the where elsewhere isn't, it is the JCP. Standardization is just antithetical to innovation. Once something is fixed in brick/mortar how can you innovate? Wicket is very comfortably located elsewhere. Martijn On Thu, Feb 12, 2009 at 10:05 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: we like the agility that the independence from any sort of a standard offers us. -igor On Thu, Feb 12, 2009 at 12:01 PM, Hoover, William whoo...@nemours.org wrote: Judging by the responses (or the lack thereof), It seems as though there isn't enough support from the Wicket community to push for something like this :( -Original Message- From: tomlist0...@gmail.com [mailto:tomlist0...@gmail.com] On Behalf Of Thomas Mäder Sent: Thursday, February 12, 2009 12:57 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide). The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled why wicket is cool and more cut your development costs in two with Wicket. From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts). Thomas On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner jcompag...@gmail.com wrote: And then come into the horrible voting/administive stuff? Long Release cycles that are controlled, features
Re: Wicket at ApacheCon EU'09 in Amsterdam
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. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. 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. look hibernate is an implementation of a persistence.. And they adapted (and where involved) into the specifications yes Ok now translate that to wicket.. What is wicket an implementation of? a webframework? ahh.. tapestry is also a webframework and struts is also a webframework They all implement the standard webframework spec.. which is the servlet spec.. So JPA Spec == Servlet Spec Hibernate == Wicket TopLink == Tapestry So wicket is already in the JSR/JCP ! we are an enhancement/implementation of the servlet spec :) ok ok. Maybe you say.. sevlet spec implementation == servlet .jar and tomcat ;) not the thing you would build on top of that again But then if you have wicket,tapestry and struts (and x and y) and then you want to define a Web Framework spec that all of them can adapt to what would that then be? What would that then gain? Would that mean that tapestry components/pages could run inside wicket? It is just not as easy to do as with a persistence spec. Which is pretty easy because so many things kind of already work the same way before they where under the same spec.. web frameworks differ quite a bit johan
Re: Wicket at ApacheCon EU'09 in Amsterdam
Hi, I can't really think of any specification which would make sense to build - there is just no need for that IMHO. If managers need something like that - there's JSF. And knowledge is growing that JSF isn't the ultimate answer. There are other open source projects embraced by managers as well without being an official standard - else why would there be so many Struts applications out there?! Also, Wicket does support a standard, which makes it quite valuable: Portlets! Does Tapestry do that? Best regards, --- Jan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket at ApacheCon EU'09 in Amsterdam
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
Re: Wicket at ApacheCon EU'09 in Amsterdam
Unfortunately, those 'idiotic managers' (and I'm not disagreeing with you) hold the purse strings. The move to Apache was a big step towards acceptance by the business types. If you try to sell a new technology with a weird name to your manager, it's not helping that there are just some guys from the internet behind this (let's not argue whether that really matters or not, it's just about the impression it gives). Let's just say this: there are at least two angles to selling a particular technology: the business angle and the technical merits. While the technical merits of Wicket are evangalized, the business case is less promoted. Thomas PS: Just for the record, I'm totally opposed to starting a wicket JSR. On Fri, Feb 13, 2009 at 10:10 AM, Johan Compagner jcompag...@gmail.comwrote: and what would a wicket standard give you? Except that those idiotic managers then say its standardized.. now you can use it why is that is a standard for ever? dont think so everything dies. But would it run on more platforms? -- Thomas Mäder Wicket Eclipse Consulting www.devotek-it.ch
RE: Wicket at ApacheCon EU'09 in Amsterdam
First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam 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. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? 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. look hibernate is an implementation of a persistence.. And they adapted (and where involved) into the specifications yes Ok now translate that to wicket.. What is wicket an implementation of? a webframework? ahh.. tapestry is also a webframework and struts is also a webframework They all implement the standard webframework spec.. which is the servlet spec.. So JPA Spec == Servlet Spec Hibernate == Wicket TopLink == Tapestry So wicket is already in the JSR/JCP ! we are an enhancement/implementation of the servlet spec :) ok ok. Maybe you say.. sevlet spec implementation == servlet .jar and tomcat ;) not the thing you would build on top of that again But then if you have wicket,tapestry and struts (and x and y) and then you want to define a Web Framework spec that all of them can adapt to what would that then be? What would that then gain? Would that mean that tapestry components/pages could run inside wicket? It is just not as easy to do as with a persistence spec. Which is pretty easy because so many things kind of already work the same way before they where under the same spec.. web frameworks differ quite a bit Answer: Ironically, the same argument that Wicket follows the Servlet specification is the same one I used in some of the dicusssions with my colleagues ;o) I think there is a lot to gain in standardizing a Swing-like architecture such as Wicket. The answer to your question is the same reason why Wicket prides itself as a truly decoupled solution that facilitates a true MVC2 model. As stated previously, it would also gain more corporate acceptance. I think that web framework only differs from other tiers because noone has come to the table with a more viable solution than JSP/JSF
Re: Wicket at ApacheCon EU'09 in Amsterdam
swing like? are there multiply implementations for swing? Can i choose one from Sun and one from X? or better said are there any desktop UI frameworks that do have multiply implementations (for the same platform??) not that i know of . There could be a reason for that so your managers just want to program against interfaces.. And be able to drop it into any container i dont see the point. That makes testing only more horrible, every container has its own bugs and slightly different behaviors... Does anybody here on the list made a application using JPA persistence and the first against hibernate and then when it was finished swapped it for something else? johan On Fri, Feb 13, 2009 at 16:59, Hoover, William whoo...@nemours.org wrote: First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam 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. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? 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. look hibernate is an implementation of a persistence.. And they adapted (and where involved) into the specifications yes Ok now translate that to wicket.. What is wicket an implementation of? a webframework? ahh.. tapestry is also a webframework and struts is also a webframework They all implement the standard webframework spec.. which is the servlet spec.. So JPA Spec == Servlet Spec Hibernate == Wicket TopLink == Tapestry So wicket is already in the JSR/JCP ! we are an enhancement/implementation of the servlet spec :) ok ok. Maybe you say.. sevlet spec implementation == servlet .jar and tomcat ;) not the thing you would build on top of that again But then if you have wicket,tapestry and struts (and x and y) and then you want to define a Web Framework spec that all of them can adapt to what would that then be? What would that then gain? Would that mean that tapestry components/pages
RE: Wicket at ApacheCon EU'09 in Amsterdam
I see that pushing for a Wicket standard is futile, but I will make one last attempt to answer some of your questions... See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 12:17 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam swing like? are there multiply implementations for swing? Can i choose one from Sun and one from X? or better said are there any desktop UI frameworks that do have multiply implementations (for the same platform??) not that i know of . There could be a reason for that Answer: Swing-like is referring to the programming model style- not the actual Swing framework (thus the word like :o). However, there could very well be other implementations for Swing, but that is another topic altogether. One of the reasons why you don't see multiple implementations of Swing is that it is part of Sun's Java Foundation Classes (JFC)- web frameworks are not ;o) so your managers just want to program against interfaces.. And be able to drop it into any container i dont see the point. That makes testing only more horrible, every container has its own bugs and slightly different behaviors... Answer: The reasoning that every container has its own bugs and slightly different behaviors is the very reason why management may want the flexibility to change implementations (the purpose for the standard in the first place). One implementation may not implement some features as well as others. Does anybody here on the list made a application using JPA persistence and the first against hibernate and then when it was finished swapped it for something else? Answer: It is highly plausible that a switch would be made from one JPA implementation to another. I know of companies that have switched from Hiberante to OpenJPA to do just that. Other reasons may include, but are not limited to: better support from one vendor to the next, discounted support through partner programs, light-weight implementation, etc. On Fri, Feb 13, 2009 at 16:59, Hoover, William whoo...@nemours.org wrote: First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam 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. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? 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
Re: Wicket at ApacheCon EU'09 in Amsterdam
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
Re: Wicket at ApacheCon EU'09 in Amsterdam
Hmm... some time ago (approx 1,5 year ) was attempts to marry JBoss Seam and Wicket. Was it successful? May be this is an example, why wicket should to be treated as a standard? Oleg On Fri, Feb 13, 2009 at 4:59 PM, Hoover, William whoo...@nemours.orgwrote: First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam 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. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? 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. look hibernate is an implementation of a persistence.. And they adapted (and where involved) into the specifications yes Ok now translate that to wicket.. What is wicket an implementation of? a webframework? ahh.. tapestry is also a webframework and struts is also a webframework They all implement the standard webframework spec.. which is the servlet spec.. So JPA Spec == Servlet Spec Hibernate == Wicket TopLink == Tapestry So wicket is already in the JSR/JCP ! we are an enhancement/implementation of the servlet spec :) ok ok. Maybe you say.. sevlet spec implementation == servlet .jar and tomcat ;) not the thing you would build on top of that again But then if you have wicket,tapestry and struts (and x and y) and then you want to define a Web Framework spec that all of them can adapt to what would that then be? What would that then gain? Would that mean that tapestry components/pages could run inside wicket? It is just not as easy to do as with a persistence spec. Which is pretty easy because so many things kind of already work the same way before they where under the same spec.. web frameworks differ quite a bit Answer: Ironically, the same argument that Wicket follows the Servlet specification is the same one I used in some of the dicusssions with my colleagues ;o) I think there is a lot to gain in standardizing a Swing-like architecture such as Wicket
Re: Wicket at ApacheCon EU'09 in Amsterdam
how will having wicket as a standard help this? look at spring, it is no jsr but a lot of projects integrate with it, and it in return integrates with other projects. anyways, there is already a start of wicket seam support by the seam folks. http://in.relation.to/Bloggers/SeamlessWicket -igor On Fri, Feb 13, 2009 at 1:05 PM, Oleg Taranenko taranenko.for...@googlemail.com wrote: Hmm... some time ago (approx 1,5 year ) was attempts to marry JBoss Seam and Wicket. Was it successful? May be this is an example, why wicket should to be treated as a standard? Oleg On Fri, Feb 13, 2009 at 4:59 PM, Hoover, William whoo...@nemours.orgwrote: First of all, thank you for entertaining this idea :o) See comments below... -Original Message- From: Johan Compagner [mailto:jcompag...@gmail.com] Sent: Friday, February 13, 2009 9:38 AM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam 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. But the examples you gave me have multiply implementations. But wicket doesnt have multiply implementations, what would that mean? That we have IComponent, IRequestCycle, ISession and IApplication and so on? And that IBM would make its own implementation of all the components including the base? And JBoss and X and Y? Answer: They do not have multiple implementations now, but they could potentially have them in the future. It would mean that other communities could follow a standard and mangement could be satisfied that Wicket has the backing of a recognized standard. There is no vendor locking for wicket.. (and all other open source web frameworks by the way) what is the locking? Answer: I agree that other frameworks that have a standard have been disastrous as far as portability between implementations (such as the loosly organized JSF specification), but the locking I'm referring to is in realation to the vendor (Wicket in this case) from a business standpoint. I for one do not have an issue with being tightly coupled to Wicket, but I can see why managment may have an issue with it. A question we need to ask ourselves from a management standpoit is if for whatever reason we had to migrate from Wicket to another framework, what revenue impact would that have on our organization in doing so? If we chose a standards base solution would this minimize the risk due to multiple vendor offerings? And wicket runs pretty much on all simple servlet containers.. Some bugs in some not counting... So give me a concreet example what a standardized wicket would look like. What vendor-independent/implementation-independent solutions there would be then.. Answer: This is a preliminary concept, but the Swing-like architecture for the web could be a starting point? 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. look hibernate is an implementation of a persistence.. And they adapted (and where involved) into the specifications yes Ok now translate that to wicket.. What is wicket an implementation of? a webframework? ahh.. tapestry is also a webframework and struts is also a webframework They all implement the standard webframework spec.. which is the servlet spec.. So JPA Spec == Servlet Spec Hibernate == Wicket TopLink == Tapestry So wicket is already in the JSR/JCP ! we are an enhancement/implementation of the servlet spec :) ok ok. Maybe you say.. sevlet spec implementation == servlet .jar and tomcat ;) not the thing you would build on top of that again But then if you have wicket,tapestry and struts (and x and y) and then you want to define a Web Framework spec that all of them can adapt to what would that then be? What would that then gain? Would that mean that tapestry components/pages could run inside wicket? It is just not as easy to do as with a persistence spec. Which is pretty easy
RE: Wicket at ApacheCon EU'09 in Amsterdam
Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, February 11, 2009 5:33 PM To: users@wicket.apache.org Subject: Wicket at ApacheCon EU'09 in Amsterdam We're happy to announce a lot of Wicket involvement at the upcoming ApacheCon in Amsterdam (23-27 March 2009) First of all we have 2 training sessions available: - Introduction to Wicket by Martijn Dashorst on Mon 23 March (http://tinyurl.com/aceu09wicket1) - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2) Both courses are hosted by core members. Martijn has co-authored Wicket in Action and Timo has been involved with WicketTester and JDave. There is no better team to get you and your team up to speed with the finest Java web framework available and start cranking out fully tested applications. Martijn will also present Wicket in Action during the normal conference days. A quick introduction to Wicket's core features in just one hour. But attending the conference will give you much more: over 60 sessions covering your favorite Apache projects. Amsterdam is great, but Wicket meetups in Amsterdam are even better! We're attempting to schedule a Wicket meetup during the conference at the conference floor. Details will follow soon. Read more about ApacheCon EU 2009 here: http://www.eu.apachecon.com/c/aceu2009/ See you in Amsterdam! Martijn - 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
Re: Wicket at ApacheCon EU'09 in Amsterdam
And then come into the horrible voting/administive stuff? Long Release cycles that are controlled, features that are discussed over and over. Hmm On 12/02/2009, Hoover, William whoo...@nemours.org wrote: Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, February 11, 2009 5:33 PM To: users@wicket.apache.org Subject: Wicket at ApacheCon EU'09 in Amsterdam We're happy to announce a lot of Wicket involvement at the upcoming ApacheCon in Amsterdam (23-27 March 2009) First of all we have 2 training sessions available: - Introduction to Wicket by Martijn Dashorst on Mon 23 March (http://tinyurl.com/aceu09wicket1) - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2) Both courses are hosted by core members. Martijn has co-authored Wicket in Action and Timo has been involved with WicketTester and JDave. There is no better team to get you and your team up to speed with the finest Java web framework available and start cranking out fully tested applications. Martijn will also present Wicket in Action during the normal conference days. A quick introduction to Wicket's core features in just one hour. But attending the conference will give you much more: over 60 sessions covering your favorite Apache projects. Amsterdam is great, but Wicket meetups in Amsterdam are even better! We're attempting to schedule a Wicket meetup during the conference at the conference floor. Details will follow soon. Read more about ApacheCon EU 2009 here: http://www.eu.apachecon.com/c/aceu2009/ See you in Amsterdam! Martijn - 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
Re: Wicket at ApacheCon EU'09 in Amsterdam
I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide). The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled why wicket is cool and more cut your development costs in two with Wicket. From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts). Thomas On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner jcompag...@gmail.comwrote: And then come into the horrible voting/administive stuff? Long Release cycles that are controlled, features that are discussed over and over. Hmm On 12/02/2009, Hoover, William whoo...@nemours.org wrote: Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, February 11, 2009 5:33 PM To: users@wicket.apache.org Subject: Wicket at ApacheCon EU'09 in Amsterdam We're happy to announce a lot of Wicket involvement at the upcoming ApacheCon in Amsterdam (23-27 March 2009) First of all we have 2 training sessions available: - Introduction to Wicket by Martijn Dashorst on Mon 23 March (http://tinyurl.com/aceu09wicket1) - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2) Both courses are hosted by core members. Martijn has co-authored Wicket in Action and Timo has been involved with WicketTester and JDave. There is no better team to get you and your team up to speed with the finest Java web framework available and start cranking out fully tested applications. Martijn will also present Wicket in Action during the normal conference days. A quick introduction to Wicket's core features in just one hour. But attending the conference will give you much more: over 60 sessions covering your favorite Apache projects. Amsterdam is great, but Wicket meetups in Amsterdam are even better! We're attempting to schedule a Wicket meetup during the conference at the conference floor. Details will follow soon. Read more about ApacheCon EU 2009 here: http://www.eu.apachecon.com/c/aceu2009/ See you in Amsterdam! Martijn - 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 -- Thomas Mäder Wicket Eclipse Consulting www.devotek-it.ch
Re: Wicket at ApacheCon EU'09 in Amsterdam
Hm no wicket jobs in switzerland? Damnn I am right now waiting for a plane that will bring me again to basel and the bern. I guess i cant stay there much longer then i do now then (1.5 week) :( The switzerland has to come to holland. :) On 12/02/2009, Thomas Mäder thomas.mae...@devotek-it.ch wrote: I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide). The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled why wicket is cool and more cut your development costs in two with Wicket. From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts). Thomas On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner jcompag...@gmail.comwrote: And then come into the horrible voting/administive stuff? Long Release cycles that are controlled, features that are discussed over and over. Hmm On 12/02/2009, Hoover, William whoo...@nemours.org wrote: Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, February 11, 2009 5:33 PM To: users@wicket.apache.org Subject: Wicket at ApacheCon EU'09 in Amsterdam We're happy to announce a lot of Wicket involvement at the upcoming ApacheCon in Amsterdam (23-27 March 2009) First of all we have 2 training sessions available: - Introduction to Wicket by Martijn Dashorst on Mon 23 March (http://tinyurl.com/aceu09wicket1) - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2) Both courses are hosted by core members. Martijn has co-authored Wicket in Action and Timo has been involved with WicketTester and JDave. There is no better team to get you and your team up to speed with the finest Java web framework available and start cranking out fully tested applications. Martijn will also present Wicket in Action during the normal conference days. A quick introduction to Wicket's core features in just one hour. But attending the conference will give you much more: over 60 sessions covering your favorite Apache projects. Amsterdam is great, but Wicket meetups in Amsterdam are even better! We're attempting to schedule a Wicket meetup during the conference at the conference floor. Details will follow soon. Read more about ApacheCon EU 2009 here: http://www.eu.apachecon.com/c/aceu2009/ See you in Amsterdam! Martijn - 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 -- Thomas Mäder Wicket Eclipse Consulting www.devotek-it.ch - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket at ApacheCon EU'09 in Amsterdam
Judging by the responses (or the lack thereof), It seems as though there isn't enough support from the Wicket community to push for something like this :( -Original Message- From: tomlist0...@gmail.com [mailto:tomlist0...@gmail.com] On Behalf Of Thomas Mäder Sent: Thursday, February 12, 2009 12:57 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide). The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled why wicket is cool and more cut your development costs in two with Wicket. From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts). Thomas On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner jcompag...@gmail.comwrote: And then come into the horrible voting/administive stuff? Long Release cycles that are controlled, features that are discussed over and over. Hmm On 12/02/2009, Hoover, William whoo...@nemours.org wrote: Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, February 11, 2009 5:33 PM To: users@wicket.apache.org Subject: Wicket at ApacheCon EU'09 in Amsterdam We're happy to announce a lot of Wicket involvement at the upcoming ApacheCon in Amsterdam (23-27 March 2009) First of all we have 2 training sessions available: - Introduction to Wicket by Martijn Dashorst on Mon 23 March (http://tinyurl.com/aceu09wicket1) - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2) Both courses are hosted by core members. Martijn has co-authored Wicket in Action and Timo has been involved with WicketTester and JDave. There is no better team to get you and your team up to speed with the finest Java web framework available and start cranking out fully tested applications. Martijn will also present Wicket in Action during the normal conference days. A quick introduction to Wicket's core features in just one hour. But attending the conference will give you much more: over 60 sessions covering your favorite Apache projects. Amsterdam is great, but Wicket meetups in Amsterdam are even better! We're attempting to schedule a Wicket meetup during the conference at the conference floor. Details will follow soon. Read more about ApacheCon EU 2009 here: http://www.eu.apachecon.com/c/aceu2009/ See you in Amsterdam! Martijn - 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 -- Thomas Mäder Wicket Eclipse Consulting www.devotek-it.ch - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket at ApacheCon EU'09 in Amsterdam
we like the agility that the independence from any sort of a standard offers us. -igor On Thu, Feb 12, 2009 at 12:01 PM, Hoover, William whoo...@nemours.org wrote: Judging by the responses (or the lack thereof), It seems as though there isn't enough support from the Wicket community to push for something like this :( -Original Message- From: tomlist0...@gmail.com [mailto:tomlist0...@gmail.com] On Behalf Of Thomas Mäder Sent: Thursday, February 12, 2009 12:57 PM To: users@wicket.apache.org Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam I totally agree that the JSR process is horrid. However, Wicket could really use some more corporate credibility (which a JSR would provide). The problem, I guess is that there are simply no corporate interests behind Wicket that would push the agenda. What wicket need is some evangelism, but I guess all the core people have real jobs. What we need is less talks titled why wicket is cool and more cut your development costs in two with Wicket. From experience, I am totally convinced that you can save 50% off your development costs if you switch to wicket (from just about any other framework), however, I've yet to find a contracting job here in Zürich where wicket is asked for (it's JSF, or even Struts). Thomas On Thu, Feb 12, 2009 at 6:36 PM, Johan Compagner jcompag...@gmail.comwrote: And then come into the horrible voting/administive stuff? Long Release cycles that are controlled, features that are discussed over and over. Hmm On 12/02/2009, Hoover, William whoo...@nemours.org wrote: Just out of curiosity... Are there any plans to push a JSR that Wicket could follow. I think there would be a lot more acceptance of Wicket if this was to happen :o) -Original Message- From: martijn.dasho...@gmail.com [mailto:martijn.dasho...@gmail.com] On Behalf Of Martijn Dashorst Sent: Wednesday, February 11, 2009 5:33 PM To: users@wicket.apache.org Subject: Wicket at ApacheCon EU'09 in Amsterdam We're happy to announce a lot of Wicket involvement at the upcoming ApacheCon in Amsterdam (23-27 March 2009) First of all we have 2 training sessions available: - Introduction to Wicket by Martijn Dashorst on Mon 23 March (http://tinyurl.com/aceu09wicket1) - Behavior-Driving Your Apache Wicket Application by Timo Rantalaiho on Tue 24 March (http://tinyurl.com/aceu09wicket2) Both courses are hosted by core members. Martijn has co-authored Wicket in Action and Timo has been involved with WicketTester and JDave. There is no better team to get you and your team up to speed with the finest Java web framework available and start cranking out fully tested applications. Martijn will also present Wicket in Action during the normal conference days. A quick introduction to Wicket's core features in just one hour. But attending the conference will give you much more: over 60 sessions covering your favorite Apache projects. Amsterdam is great, but Wicket meetups in Amsterdam are even better! We're attempting to schedule a Wicket meetup during the conference at the conference floor. Details will follow soon. Read more about ApacheCon EU 2009 here: http://www.eu.apachecon.com/c/aceu2009/ See you in Amsterdam! Martijn - 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 -- Thomas Mäder Wicket Eclipse Consulting www.devotek-it.ch - 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
Re: Wicket at ApacheCon EU'09 in Amsterdam
I guess there are advantages to being a committer ;-) But I maintain, Wicket is well established on the technical front, but it could use a push on the corporate side. Of course, I'm now waiting for the inrush of offers to prove me wrong ;-) Thomas On Thu, Feb 12, 2009 at 8:14 PM, Johan Compagner jcompag...@gmail.comwrote: Hm no wicket jobs in switzerland? Damnn I am right now waiting for a plane that will bring me again to basel and the bern. I guess i cant stay there much longer then i do now then (1.5 week) :( The switzerland has to come to holland. :) -- Thomas Mäder Wicket Eclipse Consulting www.devotek-it.ch
