Re: Quickstart application doesn't show up with 1.5.3
I did the steps that Martin described and 1) http://localhost:8080/myproject = page not found 2) http://localhost:8080 = OK /Jörgen 2012/4/3 Martin Grigorov mgrigo...@apache.org Hi, Here is what I did: 1) go to http://wicket.apache.org/start/quickstart.html 2) copy mvn archetype:generate -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.5.5 -DgroupId=com.mycompany -DartifactId=myproject -DarchetypeRepository=https://repository.apache.org/ -DinteractiveMode=false 3) paste/run it in some folder 4) cd myproject 5) mvn jetty:run ( I use Maven 3.0.3) All is fine here. On Tue, Apr 3, 2012 at 9:24 PM, Dominik Sandjaja domi...@dadadom.de wrote: Hi, I also just experienced this same problem. A plain quickstart project with 1.4.19 shows the expected page when accessing localhost:8080/myproject. Trying the same with the 1.5.5 quickstart results in the Not found message, mentioned in the first message of this thread. Same error with the snapshots of 1.5 and 6.0. I started the containers with mvn jetty:run in all cases. Is there a way to get the quickstart working again with 1.5 and up? Thanks Dominik Am Freitag, den 09.12.2011, 12:10 +0100 schrieb Martin Grigorov: Hi Gabor, It looks like there is a difference in the configured context path. I'm not sure how you start it - with mvn jetty:run or with Start.java. I'd recommend you to use Start.java. It gives you much faster development cycle. On Fri, Dec 9, 2011 at 2:15 AM, Kincses, Gabor gkinc...@paypal.com wrote: No luck with 1.5-SNAPSHOT, either, but 1.4.9. works fine. This is the error I'm getting: http://localhost:8080/myproject, with 1.5.3 the basic Wicket it works! page shows up when hitting http://localhost:8080. This doesn't happen with 1.4.9. HTTP ERROR 404 Problem accessing /myproject. Reason: Not Found Powered by Jetty:// I have tried various combinations of mvn versions (2.2.1 vs. 3.0.3) and OSes (Linux 2.6, MacOS Snow Leopard). Please help, Gabor - 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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket mentioned at Server Side Symposium
I'm not trying to start a war here and I guess this will be my only contribution to this thread so with the risk of being punished by the wicket community, I guess the speaker said like he said because wicket release numbering doesn't follow normal version numbering (with normal I mean what most other projects use). If you have x.y.z, then you should change x: if you have API breaks y: if you have new development, internal improvements or non critical bug fixes and there isnt an API break z: if you have to release a hot-fix for due to a serious bug. Releases with this numbering will on the other hand require more maintenance. A z release should be made for all previous releases which contains the bug, provided that the 'old' release is still supported. It could be the last X number of y releases or perhaps all releases made the last number of X months. /J 2011/3/21 Martijn Dashorst martijn.dasho...@gmail.com While we strive to keep binary compatibility between minor releases, i.e. the z releases of an x.y.z release path, sometimes things slip by. In principle we only allow security or blocker issues to break the API in a .z release. So we strive to make the upgrade path of 1.4.0 to 1.4.16 to be just a version number change, with an API surface the size of Wicket's it is nigh impossible to achieve 100% binary compatiblity between all minor releases (.z releases). If the speaker is talking about the y part, then yes we allow breakages and possibly even large ones. But those are always fairly easy to upgrade. The upgrade from 1.3 to 1.4 was mainly generics: a painful upgrade, but worth the effort. It could've been a x release, but we only modified the type parameter, and the rest of the API was only changed to support the generification. We voted upon the release number and with our previous 2.0 fiasco still in memory we decided to up the y part only. With Wicket 1.5 we improved the internals considerably, and improved the API as well. The upgrade path is detailed in our migration guide in the wiki. The upgrade from 1.4 to 1.5 should be not too much work. I'd rather have a framework that breaks some API in minor ways with each .y release, than a stagnant framework that is afraid to improve on its API and internals. So while he technically has a point, I think it is a category z point. Not a major one. Martijn On Mon, Mar 21, 2011 at 9:22 PM, Clint Checketts checke...@gmail.com wrote: Take the following with a grain of salt since I was told by a friend, of a friend that attended the Server Side Symposium last week. I don't have any of the details either so bear with me. Apparently in a session related to 'corporations using open source' the speaker asked if any companies were using Wicket. He cautioned that Wicket was an example of mis-managing by being known to break it's APIs in minor point-releases. In my experience with the Wicket API, I've only seen major API changes in the major releases: 1.3 - 1.4 and the upcoming 1.5. (In my book API *additions *like adding onConfigure don't count) So of course I stood up for Wicket. Even when I've proposed changes myself the core developers have done a great job of not breaking APIs. So, does anyone else know what this speaker may have been referring to regarding API breakages? -Clint -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Happy new year list!
Regards, Jörgen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
