Re: New committer: Jesse Long
w00t! Welcome Jesse! On Sun, Sep 28, 2014 at 2:47 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: The Project Management Committee (PMC) for Apache Wicket has asked Jesse Long to become a committer and we are pleased to announce that he has accepted. Jesse has been involved with Wicket for a while now and has submitted issues and provided patches for them. Being a committer enables easier contribution to the project since there is no need to go via the patch submission process. This should enable better productivity. Being a PMC member enables assistance with the management and to guide the direction of the project. Please welcome Jesse Long to our team! Welcome Jesse! -- Jeremy Thomerson http://wickettraining.com
Re: ApacheCon EU 2014: (at least) 3 wicket presentations
Sweet! I hope you share your slides (and maybe even recorded video?) with the world! On Thu, Jul 17, 2014 at 4:53 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: All, I was just notified that my 3 proposals for presentations about Wicket were accepted. Apparently I have some work to do... My proposals are below. Hope to see you there! Martijn Apache Wicket: 10 years and beyond With the Tenth Anniversary of Wicket behind us, Wicket is still one of the thriving survivors of the Great Web Framework Wars of the mid 00's. Is there a future for server-side frameworks? In this presentation Martijn Dashorst provides a brief history of Wicket. With a State of the Wicket, Martijn will look at who is currently using Wicket, the community and current release plans. The majority of this session will be dedicated to the future of Wicket: does a component oriented, Java web framework have a future in the era of native clients and client side JavaScript frameworks? Martijn will layout the plans of making Wicket more productive for current users, on integrating better with JavaEE technologies and much more. Wicket and Java EE sitting in a tree Apache Wicket strives to enable developers to be very productive and craft maintainable web applications. Java EE also enables developers to achieve high productivity. So what happens when you combine both technologies? In this session Martijn Dashorst shows how to leverage the available Java EE technologies such as CDI, JPA, Bean Validation and JAX-RS in your Wicket applications. Wicket Puzzlers Apache Wicket is a web framework that enables you to write maintainable web applications. However there are a lot of different ways in which you can shoot yourself in your own foot, or write code that seems it should work but doesn't, or has odd side effects. In this presentation, Martijn Dashorst will present several puzzlers in the same format as the acclaimed Java Puzzlers presentation. He will present the case, offer several choices and then present the correct answer. -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Jeremy Thomerson http://wickettraining.com
Re: Apache + GitHub step 1
Yes! On Wed, Feb 12, 2014 at 2:18 AM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, Just noticed https://blogs.apache.org/infra/entry/improved_integration_between_apache_and We want all of it, right ?! Martin Grigorov Wicket Training and Consulting -- Jeremy Thomerson http://wickettraining.com
Re: Wicket-5353: Wrap feedback messages in a model instead of using Serializable objects
Here's my comment (copied from my comment on the PR). Note that I whipped up the gist quickly, so it may not compile, but it shows the intent. I don't think we need this PR. It could easily be accomplished by overriding newMessageDisplayComponent or by the following change: https://gist.github.com/jthomerson/6595716 On Tue, Sep 17, 2013 at 10:49 AM, Rafael W. rafael@web.de wrote: Hello everybody, I would like to put https://issues.apache.org/jira/browse/WICKET-5353 to dicussion. Attached, you can find an example of a Wicket application that would benefit from that change. (Simly run wicket-async-task-demo with jetty:run in Maven.) Generally, I want feedback messages to be represented by models rather than by Serializables in order to allow more multithreading in Wicket. The example contains a simple progress bar component where tasks are run in background threads in order to keep the Wicket application responsive. (I mostly use Wicket in Desktop-style applications where the attached component is tremendously useful for me.) The problem with the Serializable solution for feedback messages is that the messages have to be assembled at the time the error occurs, not at the time the message is to be displayed. In my believe, this is a misconception that can easily be corrected. I described the topic further in the Jira issue above. Thank you for your feedback. Regards, Rafael Winterhalter -- Jeremy Thomerson http://wickettraining.com
Re: Add .map files to default allowed files.
On Sat, Sep 7, 2013 at 7:12 AM, Martin Grigorov mgrigo...@apache.orgwrote: I suggest to remove the .map files for now and re-add them again when they become more popular some day. +1 - and then I'm not even sure that it should really be allowed by default since they are for *debugging* in *production*. It seems like this should by default be disabled and up to a user to add to a whitelist if $someConditionTheyDefine. -- Jeremy Thomerson http://wickettraining.com
Re: [VOTE] Accept the Wicket Free Guide as a part of Apache Wicket
[X] Yes, accept the Wicket Free Guide to incorporate into our project On Sun, Aug 18, 2013 at 10:48 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: [X] Yes, accept the Wicket Free Guide to incorporate into our project [ ] No, don't accept the Wicket Free Guide Martijn -- Jeremy Thomerson http://wickettraining.com
Re: buildbot failure in ASF Buildbot on wicket-branch-6.x
Should we do something to avoid that? Could the different branches use different ports? Or some buildbot-config? On Fri, Aug 2, 2013 at 7:58 AM, Martin Grigorov mgrigo...@apache.orgwrote: You should commit with some delay between master and wicket-6.x because otherwise wicket-examples' test fail to use the same http port... On Fri, Aug 2, 2013 at 1:55 PM, build...@apache.org wrote: The Buildbot has detected a new failure on builder wicket-branch-6.x while building wicket. Full details are available at: http://ci.apache.org/builders/wicket-branch-6.x/builds/103 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: hemera_ubuntu Build Reason: scheduler Build Source Stamp: [branch wicket-6.x] cdfa92ca3f8af8012a8f5c53076c1ffb7ce65944 Blamelist: svenmeier s...@meiers.net BUILD FAILED: failed compile sincerely, -The Buildbot -- Jeremy Thomerson http://wickettraining.com
Re: git commit: WICKET-5071 use url as clientUrl
On Fri, Jul 12, 2013 at 7:34 AM, Sven Meier s...@meiers.net wrote: Sorry, that was the wrong issue number in the clipboard. Changing the last commit message after push? Linus says don't to it: http://stackoverflow.com/**questions/457379/how-do-i-** edit-an-incorrect-commit-**message-in-git-ive-pushed/**457396#457396http://stackoverflow.com/questions/457379/how-do-i-edit-an-incorrect-commit-message-in-git-ive-pushed/457396#457396 Besides, history rewriting is disallowed at ASF (for good reason).
Re: Michael Mosmann is a committer and PMC member!
Welcome Michael! On Mon, Jul 1, 2013 at 11:47 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: welcome! -igor On Mon, Jul 1, 2013 at 2:51 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Please welcome Michael Mosmann as our newest addition to the Wicket team! Michael has been a long time contributor to Wicket, and even wrote a book on the subject. His day to day work keeps him busy with Wicket so we are very happy that Michael wanted to join our band of merry men! Martijn -- Jeremy Thomerson http://wickettraining.com
Re: [VOTE] Release Apache Wicket 6.9.0
On Mon, Jun 24, 2013 at 8:18 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Mon, Jun 24, 2013 at 1:59 PM, Martin Grigorov mgrigo...@apache.org wrote: I've fixed 5234 (https://issues.apache.org/jira/browse/WICKET-5248) and explained a workaround for the problem until 6.10 is out. I think it is OK to live with this problem until 6.10 is released. It has been broken until now for all 1.5.x and 6.x versions so it seems it is not so common problem. If it was broken before, it should not hold the release unless its a security issue IMO. So +1 to what Martin said. Agree with Martin and Martijn. +1
Re: Authorization for IResource
Looks good to me. I'd just mention one very minor thing: that there is at least one file that you added with Eelco / Jonathan as the @author. On Mon, Jun 17, 2013 at 5:39 AM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, https://issues.apache.org/jira/browse/WICKET-5012 explains a problem that there is no authorization for requests to IResource. A possible solution for this problem can be found in branch '5012-authorize-resources'. The diff can be seen at: https://git-wip-us.apache.org/repos/asf/wicket/repo?p=wicket.git;a=commitdiff;h=88b5d5cb482bc7bb22e2ceb9503e5056b0e89572 It tries to follow the logic for authorizing components. By default a request that is not authorized will lead to a response with error code 403 (Forbidden). Please take a look and give feedback. Thanks! -- Jeremy Thomerson http://wickettraining.com *Ask me about our plans for on-line training lessons.*
Re: JavaScript functional tests
Will we need to add this as a manual test step in our build / release cycle? Or will there be some way of automating it built into our release script(s)? On Mon, Jun 17, 2013 at 1:19 PM, Martin Grigorov mgrigo...@apache.orgwrote: I use QUnit as testing library. Node.js is required only to automate the run of the tests (in headless mode) in PhantomJS (WebKit). At the moment I run the tests by just loading http://localhost:8080/js-test/all.html in any browser. Try it! You will like it! I'll merge the branch soon. On Mon, Jun 17, 2013 at 8:13 PM, Cedric Gatay gata...@gmail.com wrote: Testing JS is a good thing to me, is there any other javascript testing framework without such prerequisite (Node.js) ? At SRMvision, we use Jasmine which does not require any other setup. Anyway, I think it should be part of the Maven build process if we want them to be useful. Regards, __ Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_Gatay) http://code-troopers.com | http://www.bloggure.info | http://cedric.gatay.fr On Mon, Jun 17, 2013 at 4:20 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: No problem... the more tests the merrier Martijn On Mon, Jun 17, 2013 at 3:05 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, I just pushed branch wicket-examples-gym-tests. It contains some tests based on the idea described at http://wicketinaction.com/2012/11/javascript-based-functional-testing/ To run the tests one has to start the examples and load http://localhost:8080/js-test/all.html Is there anyone against these tests ? I'd like to add some coverage to Wicket Examples and to practice my JS coding skills. At the moment both the old JS tests (wicket-core/src/test/js) and these ones should be executed manually. I can integrate them in Maven but them all developers and CI machines should have Node.js Do we want the tests in the build or should I leave them as now ? -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Jeremy Thomerson http://wickettraining.com *Ask me about our plans for on-line training lessons.*
Re: Website: Fisheye link outdated
I'll pass this to infra to see. I'm not sure either. On Mon, Jun 10, 2013 at 8:19 AM, Martin Grigorov mgrigo...@apache.orgwrote: I have no idea who has admin account for this service. On Mon, Jun 10, 2013 at 3:17 PM, Guillaume Smet guillaume.s...@gmail.com wrote: Hi, While I'm at it, the Fisheye link of the Wicket site (left menu, Contribute section) points to https://fisheye6.atlassian.com/browse/wicket/trunk which is still linked to the Subversion repository AFAICS. We should either point elsewhere (github or Apache gitweb), remove the link or update the Fisheye configuration to point to the git repository. If doable, the latter would be better as far as I'm concerned as it's a useful tool. Thanks. -- Guillaume -- Jeremy Thomerson http://wickettraining.com *Ask me about our plans for on-line training lessons.*
Re: Website: Fisheye link outdated
Reported to Infra: https://issues.apache.org/jira/browse/INFRA-6376 On Mon, Jun 10, 2013 at 11:21 AM, Jeremy Thomerson jer...@wickettraining.com wrote: I'll pass this to infra to see. I'm not sure either. On Mon, Jun 10, 2013 at 8:19 AM, Martin Grigorov mgrigo...@apache.orgwrote: I have no idea who has admin account for this service. On Mon, Jun 10, 2013 at 3:17 PM, Guillaume Smet guillaume.s...@gmail.com wrote: Hi, While I'm at it, the Fisheye link of the Wicket site (left menu, Contribute section) points to https://fisheye6.atlassian.com/browse/wicket/trunk which is still linked to the Subversion repository AFAICS. We should either point elsewhere (github or Apache gitweb), remove the link or update the Fisheye configuration to point to the git repository. If doable, the latter would be better as far as I'm concerned as it's a useful tool. Thanks. -- Guillaume -- Jeremy Thomerson http://wickettraining.com *Ask me about our plans for on-line training lessons.* -- Jeremy Thomerson http://wickettraining.com *Ask me about our plans for on-line training lessons.*
Re: Upgrade jQuery to 1.10.0 in Wicket 6.x ?
On Wed, May 29, 2013 at 4:40 PM, Martin Grigorov mgrigo...@apache.orgwrote: The real question is: how often we should upgrade jQuery ? I'd think each X version we release should probably use the latest production / stable jQuery version. -- Jeremy Thomerson http://wickettraining.com *Ask me about our plans for on-line training lessons.*
Re: A newer, flatter design for wicket site
I like the goal of improving the site. I think some of the previous commenters nailed the changes to the beta that we would need. In particular (and in rough order of what I see as their importance): 1. Fluid design - let's use Bootstrap. It's easy and ubiquitous. It gives us fluid (rescalable) design easy as well as some of the other things mentioned. 2. Jumbotron - agree with Mike - it's too big, maybe entirely unnecessary. If we're going to have a hero box or jumbotron at the top, it needs to be of use - advertising something. But I think the six-box thing just below the jumbotron is much more attractive for above the fold content - and it's useful. 3. consistency in coloring / logo ... is the blue an intentional change from Wicket orange? If so, I think we need to think about the ramifications - an entire rebrand (including wicket-examples, probably a new logo, etc). Easy == stick with the orange. 4. fixed header - I think it is useful - bootstrap would give us this 5. the sections of the page could likely be distinguished from each other a bit more with more obvious section headers (news, downloads, etc). I worry, too, about how to navigate on pages other than the homepage. If we have the flat design where the top navbar on the homepage only contains links to sections on that page, what happens when you are on another page of the site? How do you navigate back home? It seems bad to have a different navigation on those other pages than on the homepage. Do you have an example of how other flat websites handle this? Many thanks for all the work on this and everything else Martijn! -- Jeremy Thomerson http://wickettraining.com *Ask me about our plans for on-line training lessons.*
Re: Component setDefaultModel
On Thu, Sep 27, 2012 at 1:59 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: ok. lets start with a bit of history to have more context. setDefaultModel() only exists because of type-erasure. before wicket supported generics all components had a public setModel() method. so, one might say that having a public setModel() is the wicket way because it was there since 1.0. just to establish the baseline. lets take a concrete example of FormComponent. right now it has a public setModel() method, but by your thinking we would have to make both setDefaultModel and setModel methods protected, because we do not know that all FormComponents support changing the model. after all, a common subclass of FormComponent is FormComponentPanel which pretty much always distributes its model. so, we leave it to subclasses of FormComponent and FormComponentPanel to decide whether or not to override setModel() to make it public. a TextField would make its setModel() public - because it properly handles the usecase, correct? so it is still possible for your developers to call setModel() on a textfield and rewire it so it no longer links with a model of another component correctly. so we are now back to square one with the addition that a lot of components have to override setModel() just to change its visibility from protected to public - introducing a lot of noise. im all for making the code better, but i do not think that this change does. in the end, the developer has to know what the method does if they chose to call it. -igor +100 ... there are valid usecases for calling setModel and setDefaultModel. Very valid usecases. If you, in your programming model, don't want your developers to call setModel/setDefaultModel ... tell them not to. If you have developers that don't understand / listen to / follow your direction, it's not a Wicket problem. For that, set up some kind of code-check that looks for that and other conventions that you follow. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Component setDefaultModel
On Thu, Sep 27, 2012 at 3:33 PM, tetsuo ronald.tet...@gmail.com wrote: What about calling APanel.setDefaultModelObject(B.getObject()) instead of APanel.setDefaultModel(B)? That's to replace an object inside a model. There are very valid usecases for actually replacing a model. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [mostly devs] flyouts are dead
On Thu, Sep 20, 2012 at 11:59 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: we have decided to move away from flyouts because of various ux problems. i have deprecated FlyoutAction and introduced ModalAction which works as a drop in replacement. things to lookout for when doing the migration: when you switch over to modal action you may want to pass in an extra constructor arg that controls the title of the modal. by default it will set the title to the name of the action, but sometimes an action called Edit does not give enough context so use the (Edit, Edit Semester Requirement) constructor. switching over requires some markup tweaks as well. for example, the title (Edit Semester Requirement) above is currently embedded in the flyout markup - so that needs to be removed. also, Leslie has to change some css to make alignment work. if you switch over you have to let her know. actionbar now has closeModal() so when you are done migrating your code change calls to closeFlyout() to use closeModal() instead. i will be slowly moving bits and pieces away from flyouts during my slack time at a rate that wont burden Leslie so i may not get to a lot. i will also only be migrating the actionbar stuff first. we should probably set up tech debt at the end of this itreration to handle the rest of the places. -igor Wrong email address? -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Releasing in a semver world (= 6.x)
On Tue, Sep 11, 2012 at 8:18 AM, Andrea Del Bene an.delb...@gmail.comwrote: +1 for B. IMHO it's more rational We now live in a semver world and we need to agree on some basics: how we are going to maintain and release our software. From what I have heard from several folks in jira, mail, IRC and direct communication is that we have basically 2 camps: A. develop and release bug fixes until we we start developing for minor/major releases 6.1 (and 7.0). versus B. develop and release minor releases, only backporting critical bugs and releasing bug fix releases in case of critical bugs As we are following semver, both are valid strategies. Option A would require separate branches for 6.0.z, and 6.y Option B would require only branches 6.y.z when critical bugs are found—which should be rare. Option A would probably result in some releases like: - 6.0.1, 6.0.2, 6.0.3, 6.1.0, 6.0.4, 6.1.1, 6.1.2, 6.1.3, 6.0.5, 6.2.0, 6.1.4 Whereas option B should result in releases like: - 6.1.0, 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.4.1 What do you think? Martijn So, just to be clear - this means that when I fix a bug in master right now I put fix version of 6.1.0 in, right? -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Releasing in a semver world (= 6.x)
On Thu, Sep 13, 2012 at 9:34 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Thu, Sep 13, 2012 at 4:25 PM, Jeremy Thomerson jer...@wickettraining.com wrote: So, just to be clear - this means that when I fix a bug in master right now I put fix version of 6.1.0 in, right? Yup. I propose that for each back port to a possible x.y.z release we at least ping dev@ prior to making one: it costs time and effort to actually perform such a release. Seems reasonable to me. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Releasing in a semver world (= 6.x)
On Thu, Sep 13, 2012 at 9:40 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: As for performing the releases, I propose we maintain a ~4 week schedule for x.y.0 releases, and reserve x.y.z (z 0) for botched releases. So our release calendar would become something like: 6.1.0 - build on fri 21-09-2012 - release on tue 25-09-2012 6.2.0 - build on fri 19-10-2012 - release on tue 23-10-2012 6.3.0 - build on fri 16-11-2012 - release on tue 20-11-2012 ... I intend to be the release manager for the 6.y.0 releases. WDYT? I like it. My OCD side wonders if we should have used two-digit numbers ( at least for y and z ) to improve sortability (6.01.00) ... but then those look kind of ugly. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Releasing in a semver world (= 6.x)
On Thu, Sep 13, 2012 at 9:54 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Thu, Sep 13, 2012 at 4:45 PM, Jeremy Thomerson jer...@wickettraining.com wrote: My OCD side wonders if we should have used two-digit numbers ( at least for y and z ) to improve sortability (6.01.00) ... but then those look kind of ugly. FUGLY is a proper characterization. And I just say that we should probably start looking into wicket 7 around 6.3/6.4-ish. Do we have a roadmap somewhere of any big changes that would be in 7? -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Wicket 1.5 - duplicate JS detection broken?
I haven't had time to dig into this, but has anyone else seen where
duplicate JS detection is broken in 1.5.x? For instance, add this twice in
your page:
add(new AbstractDefaultAjaxBehavior() {
@Override
protected void respond(AjaxRequestTarget target) {
}
@Override
public void renderHead(Component component, IHeaderResponse
response) {
super.renderHead(component, response);
response.renderJavaScript(function foo() { wicketAjaxGet(' +
getCallbackUrl() + '); }, foo-func);
}
});
I end up with two JS blocks in the output, both with the ID foo-func.
Since I provided an ID that was the same for both behaviors, Wicket should
have only rendered one of those, right?
I hope to have time to debug next week if others confirm they've seen this
and I'm not missing something simple due to sleep deprivation :)
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
AllExceptFeedbackMessageFilter
All, I created this blog post [1] last year and in quite a few of my Wicket classes people ask about how to do this same thing. I can commit it to core in 1.5 / 6.0 if others think it would be useful there and don't see any problems doing so. The only problem I have with it is the limitation that is noted at the bottom of the post - that when you are doing the traversal as shown, you can only have a single instance on the page. [1] http://www.jeremythomerson.com/blog/2011/01/catching-all-feedback-messages-that-arent-rendered-by-other-feedback-panels/ -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Multiple Git Workspaces From Single Repo
Like many of you I need to be able to change between 1.4.x, 1.5.x and master branches quite a bit in my work. But with different maven sub-modules within each of those branches, etc, it can be quite messy on Eclipse to just use git checkout to switch between branches. So, I have recently started working with a single git repo and several different working directories based on that repo. Doing it this way gives me the ability to have separate workspaces. But they're all based on the same repo, so if I need to cherry pick a commit from one branch to the other I can commit it in one workspace and change directory to the other (branch's) workspace and cherry pick it. I never mess up Eclipse by changing branches that way. Here's a little script that can get you set up the same way if you'd like to try it: http://pastebin.com/dmzuvvXY -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Site updates
On Wed, Apr 4, 2012 at 7:58 PM, Jesse Long j...@unknown.za.net wrote: Two minor changes to the site. (Would love to do a github pull request, but cant find the site in git). Applied. Rebuilt and committed with #1309632. The site source hasn't moved to git because infra@ASF automatically updates our site from SVN using svnpubsub, and I don't think they have a git equivalent (yet). Thanks for the patch! You should see the changes go live shortly. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
GitHub Pull Requests
After I saw the pull request below [1] I realized that our GitHub mirror wasn't ever switched to pull from our Git@ASF repo. I requested that it be changed. Jukka apparently updated it because it is now in sync. This means future pull requests should automatically close themselves once the commit hashes from the pull request appear in the requested branch. [1] https://github.com/apache/wicket/pull/4 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: about webshere and relative url redirects: https://issues.apache.org/jira/browse/WICKET-3258
Johan (and others), I just noticed this thread (and then noticed that you cc'd me). I never have actually run websphere for any of my applications. I was on-site at a client and they had this problem. We dug through it, I committed that extension point and then immediately wiped it from my memory :) This commit didn't actually fix anything for this situation. It simply gave the client a way that they could override sendRedirect. IIRC they overrode it and converted URLs from relative to absolute before passing the redirect off to the servlet response. They had tons of app-specific URL-handling code, but the same idea should work for anyone (I think). HTH -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Mon, Feb 6, 2012 at 11:06 AM, Johan Compagner jcompag...@gmail.comwrote: Websphere, i am currently testing our product in a war deployment with the latest wicket 1.4 code But i am still bumping against this with Websphere 8.0.2 was it really fixed? Do i need a setting somehow? It is really weird for example if this is the url http://jcompagner-pc:9080/servoy/servoy-webclient/solutions/solution/RadioTest we send ../../?wicketurl which is correct because we should get: http://jcompagner-pc:9080/servoy/servoy-webclient/?wicketurl but what i get: http://jcompagner-pc:9080/?wicketurl weird thing is if i do this: http://jcompagner-pc:9080/servoy/servoy-webclient/solutions/solution/RadioTest/a/b we send: ../../../../?wicketurl and then it works! But if i then play with it a bit http://jcompagner-pc:9080/servoy/servoy-webclient/solutions/solution/RadioTest/a/b and then force that this is send: ../../../?wicketurl i get: http://jcompagner-pc:9080/servoy/servoy-webclient/solutions/?wicketurl so that is still correct, there is 1 less removed.. But now i remove another one: ../../?wicketurl then i get this: http://jcompagner-pc:9080/?wicketurl ??? so now it seems to only use the servlet path/context again! if i kill another: ../?wicketurl http://jcompagner-pc:9080/servoy/?wicketurl so it seems that if the relative url has context/servletpath up dirs (so 1 or 2 ../) then it sees it as the context/servletpath thing and if it is more so i have 3 times ../ it sees it as the whole url!! Is Websphere trying to be to smart??
Re: [vote] release Wicket 1.5.4.1
+1 On Mon, Jan 16, 2012 at 2:39 PM, Peter Ertl pe...@gmx.org wrote: +1 working here Am 16.01.2012 um 20:04 schrieb Igor Vaynberg: This vote is to release wicket 1.5.4.1 (vote for 1.5.4 failed) Branch http://git-wip-us.apache.org/repos/asf/wicket/?p=wicket.git;a=shortlog;h=refs/heads/build/wicket-1.5.4.1 Artifacts http://people.apache.org/~ivaynberg/wicket-1.5.4.1/dist/ Maven repo https://repository.apache.org/content/repositories/orgapachewicket-079/ Changelog https://issues.apache.org/jira/secure/IssueNavigator.jspa?jqlQuery=fixVersion+%3D+%221.5.4%22+AND+project+%3D+WICKET This vote ends Thursday, January 19th at 11:00am (GMT-8) Please test the release and offer your vote. The Wicket team! -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [vote] release wicket 1.5.4
On Tue, Jan 10, 2012 at 4:10 PM, Martin Dilger martin.dil...@googlemail.com wrote: +1 Am 10.01.2012 20:04 schrieb Igor Vaynberg igor.vaynb...@gmail.com: This vote is to release wicket 1.5.4 Branch http://git-wip-us.apache.org/repos/asf/wicket/?p=wicket.git;a=shortlog;h=refs/heads/build/wicket-1.5.4 Artifacts http://people.apache.org/~ivaynberg/wicket-1.5.4/dist/ Maven repo https://repository.apache.org/content/repositories/orgapachewicket-045/ Changelog https://issues.apache.org/jira/secure/IssueNavigator.jspa?jqlQuery=fixVersion+%3D+%221.5.4%22+AND+project+%3D+WICKET This vote ends Friday, January 13th at 11:00am (GMT-8) Please test the release and offer your vote. The Wicket team! +1 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Please welcome Emond Papegaaij as a committer for Wicket
Welcome aboard! On Fri, Dec 30, 2011 at 10:26 AM, Emond Papegaaij emond.papega...@topicus.nl wrote: Thank you all for the confidence you have in my work! I'm really proud to be a member of the Wicket team and am looking forward to get some real work done. I've already pushed some patches for a few tickets, broke most testcases and fixed them again, so it's looking good :) On Friday 30 December 2011 14:59:39 Martijn Dashorst wrote: I am pleased to announce that the Wicket PMC has voted Emond Papegaaij as our newest member. Please welcome him to our team! Welcome Emond! Enjoy the New Year with Wicket! Martijn -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Roadmap for Wicket 6.0
On Thu, Dec 22, 2011 at 2:29 AM, Sven Meier s...@meiers.net wrote: Hi Gabriel, there are several components which are in need of an overhaul, especially Javascript heavy implementations like modal window and autocomplete. Before we have decided on these, I'm reluctant to shove more code into the framework. It would be very nice to use a TreeProvider instead of the swing TreeNode. Everyone can start using http://code.google.com/p/**wicket-tree/http://code.google.com/p/wicket-tree/right away. I'm planning to move the 6.0 implementation to wicket-stuff (with minor changes), hopefully we'll get more feedback about its usefulness then. Sven, Thoughts about moving your tree to wicket-extensions rather than wicket-stuff? If it's supported by core committers and likely to make it into a future release of Wicket, I'd rather see it there than wicket-stuff. Wicket stuff is still widely regarded as the wild west of Wicket plugins and has a hard time getting wider adoption by many of the companies I visit (and rightly so in many regards, despite the heroic efforts of Mike and others). -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Wicket source code moved to Git
On Tue, Dec 20, 2011 at 11:46 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Tue, Dec 20, 2011 at 11:20 PM, Clint Checketts checke...@gmail.comwrote: Jeremy, Will Git development mimic the current subversion workflow, or will we see we see a more Git-ish way like 'git flow'? See- http://nvie.com/posts/a-successful-git-branching-model/ I think at least the core developers are already trying to adopt a more git-like work flow. Look at some of the ajax/JS stuff that happened on GH prior to being merged into SVN. I'm definitely in favor of a more Git-ish way of doing things. I realize that likely the answer is 'we don't know yet', so I'd like to get the conversation going. I'd suggest: give us through the weekend for the committers to get git (hehe pun) setup and in use, then let's start a separate discussion. I also say this because of a very large thread on infrastructure-dev right now [1] about the current git hook that requires all committers to have an @ apache.org email address, which means for me to pull from your GH repo, for instance, I'd need to rewrite the history some. I think that this requirement will go away (the message I linked to is the first with real weight that says it can go away), but whatever the outcome of that thread is will have a major impact on our git-flow. Involvement with that ongoing thread among other conversations has kept from from actually playing with our git repo. I hope the distraction will be gone soon. [1] http://markmail.org/message/jsnmxdzf5qkkrvwg FYI... here's an update that the $contributorEmail =~ /.*@apache.org/requirement is now gone. See [2] This should make it easier to integrate a standard git workflow where we can merge branches from various users. Of course, the committers still need to do our due diligence to ensure code provenance. [2] http://markmail.org/message/3v47l7747xntqreq -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Wicket source code moved to Git
On Wed, Dec 21, 2011 at 1:40 PM, Johan Compagner jcompag...@gmail.comwrote: hmm i use EGit but some how i always get not authorized if i try to push something I am quite sure the username/password is correct, but will recheck it, i use this url: https://jcompag...@git-wip-us.apache.org/repos/asf/wicket.git URL is correct. Pushing worked for me (I took your URL, changed to my UN, cloned, committed, pushed). Password might be wrong. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Wicket source code moved to Git
Our SVN repository is now set read-only. For information about getting started with Git @ ASF, see [1]. The JIRA issue where we were converted is [2]. Unfortunately I will not be able to experiment much (if at all) with this until tomorrow night. Feel free to reply to this thread if you have problems migrating. I'll try to help work through those. For now you are not allowed to push any commits that have the Git committer field set to a non-Apache email address, although I hope that requirement will change very soon. Is there a volunteer willing to get our build infra set up with the new Git repo? [1] http://git-wip-us.apache.org/#committers-getting-started [2] https://issues.apache.org/jira/browse/INFRA-4204 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Wicket source code moved to Git
On Tue, Dec 20, 2011 at 11:20 PM, Clint Checketts checke...@gmail.comwrote: Jeremy, Will Git development mimic the current subversion workflow, or will we see we see a more Git-ish way like 'git flow'? See- http://nvie.com/posts/a-successful-git-branching-model/ I think at least the core developers are already trying to adopt a more git-like work flow. Look at some of the ajax/JS stuff that happened on GH prior to being merged into SVN. I'm definitely in favor of a more Git-ish way of doing things. I realize that likely the answer is 'we don't know yet', so I'd like to get the conversation going. I'd suggest: give us through the weekend for the committers to get git (hehe pun) setup and in use, then let's start a separate discussion. I also say this because of a very large thread on infrastructure-dev right now [1] about the current git hook that requires all committers to have an @ apache.org email address, which means for me to pull from your GH repo, for instance, I'd need to rewrite the history some. I think that this requirement will go away (the message I linked to is the first with real weight that says it can go away), but whatever the outcome of that thread is will have a major impact on our git-flow. Involvement with that ongoing thread among other conversations has kept from from actually playing with our git repo. I hope the distraction will be gone soon. [1] http://markmail.org/message/jsnmxdzf5qkkrvwg -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: git commit: fixed typo. first push. woot
Just bringing this to the dev@ list. It's definitely a milestone!! ivaynberg gets the first push trophy! On Tue, Dec 20, 2011 at 11:10 PM, ivaynb...@apache.org wrote: Updated Branches: refs/heads/trunk 24d17d5be - 500d9caad fixed typo. first push. woot Project: http://git-wip-us.apache.org/repos/asf/wicket/repo Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/500d9caa Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/500d9caa Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/500d9caa Branch: refs/heads/trunk Commit: 500d9caad302274423f1089e428e9824865268b0 Parents: 24d17d5 Author: Igor Vaynberg ivaynb...@apache.org Authored: Tue Dec 20 20:10:17 2011 -0800 Committer: Igor Vaynberg ivaynb...@apache.org Committed: Tue Dec 20 20:10:17 2011 -0800 -- release-igor.sh |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- http://git-wip-us.apache.org/repos/asf/wicket/blob/500d9caa/release-igor.sh -- diff --git a/release-igor.sh b/release-igor.sh index d55ef0b..d4a9377 100755 --- a/release-igor.sh +++ b/release-igor.sh @@ -33,7 +33,7 @@ stty -echo read passphrase stty $stty_orig -# test the GPGP passphrase to fail-fast: +# test the GPG passphrase to fail-fast: echo $passphrase | gpg --passphrase-fd 0 --armor --output pom.xml.asc --detach-sig pom.xml gpg --verify pom.xml.asc if [ $? -ne 0 ]; then -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Request for help: simple GitHub test
If anybody here has ten minutes available to help me test some GitHub features, please see [1] and complete the first batch of steps. Basically, fork that repo, add a commit or two, and then create a pull request for me. I'll take it from there. If I can get a few pull requests (or even a dozen), it will help me test some features I'd like to work on for Git@ASF. [1] https://github.com/jthomerson/github-playground Thanks! -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Wicket will be migrating to Git
The ASF has been testing a new Git infrastructure that will enable projects to be hosted on Git rather than SVN. I'm happy to announce that it was decided today that the Wicket project will be one of the first projects to be migrated. We will be scheduling this as soon as possible. Timing will depend on the availability of the infra guys and guys on our side as well. As soon as I have more details I will pass them along. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: integrating CDI into Wicket
Awesome! Can't wait for the next article. PS - Sent from a tablet. Please excuse typos, spelling and compiler errors. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org On Nov 15, 2011 1:01 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: if you want to learn how to use CDI with Wicket i just wrote a short blog about it: https://www.42lines.net/2011/11/15/integrating-cdi-into-wicket/ -igor
Re: [vote] release wicket 1.5.3
+1 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Fri, Nov 11, 2011 at 12:27 PM, Pedro Santos pedros...@gmail.com wrote: +1 Pedro Henrique Oliveira dos Santos 2011/11/11 Andrea Del Bene adelb...@ciseonweb.it: +1 This vote is to release wicket 1.5.3 Branch http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5.3 Artifacts http://people.apache.org/~ivaynberg/wicket-1.5.3/dist/ Maven repo https://repository.apache.org/content/repositories/orgapachewicket-172/ Changelog https://issues.apache.org/jira/secure/IssueNavigator.jspa?jqlQuery=fixVersion+%3D+%221.5.3%22+AND+project+%3D+WICKET This vote ends Saturday, November 12th at 1:00pm (GMT-8) Please test the release and offer your vote. The Wicket team!
Re: [vote] release wicket 1.5.2 take 3
+1 On Fri, Oct 21, 2011 at 11:03 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: +1 -igor On Thu, Oct 20, 2011 at 9:34 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: This vote is to release wicket 1.5.2 (take 3) Branch http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5.2 Artifacts http://people.apache.org/~ivaynberg/wicket-1.5.2/dist/ Maven repo https://repository.apache.org/content/repositories/orgapachewicket-084/ Changelog https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12318078 This vote ends Sunday, October 23nd at 9:30pm (GMT-7) Please test the release and offer your vote. The Wicket team! -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Proposal: Moving wicketstuff.org Jenkins instance to a linux server (I volunteer to manage it)
On Thu, Oct 13, 2011 at 11:53 PM, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: Hello, Jenkins currently runs at wicketstuff.org/hudson. The wicketstuff.orgserver is running FreeBSD which is not directly supported by Jenkins and so upgrading and installing related tooling becomes a burden on the server admins. Recently there has been intermittent instability that causes jenkins to become unavailable and prevents developers from being easily able to generate and test new snapshot releases. My proposal is that we take advantage of the Jenkins community support for Linux that includes auto-installers and binary packages and switch to running the wicketstuff.org Jenkins instance on a Linux box. I am volunteering to host this on a VPS I have and to take care of the server side admin. If this is acceptable I would suggest moving jenkins from wicketstuff.org/hudson to a DNS A name like ci.wicketstuff.org that could point at my server. Then depending on the load I might ask to have the wicketstuff.org server setup as a slave to sometimes assist in building the projects but not be the main access point for the developers. Once this is setup I would also be interested in letting others contribute slaves to help with the build. In the past when I noticed that the wicketstuff.org/hudson server was down I would setup a private Jenkins instance to take care of building the SNAPSHOT's because I didn't want to run it in public with the same anyone can signup privileges. To get around this issue I have written a Jenkins authentication/authorization plugin that will restrict access to only members of a named github organization (i.e. only github users that are a member of the wicketstuff organization can access and invoke builds. This will let us manage access entirely through Github. The only restriction on the plugin right now is that the users affiliation in the team needs to be publicized. Plugin Link: https://wiki.jenkins-ci.org/**display/JENKINS/Github+OAuth+** Plugin https://wiki.jenkins-ci.org/display/JENKINS/Github+OAuth+Plugin I've published the 0.6 version of this plugin which now supports a post commit hook from github to trigger builds (i.e. no more @hourly polling is required). The test instance is here: http://rivulet.ca:8080/ Anyone with commit access in github that is a public member of the any team in the wicketstuff project can login and have the trigger build permission. Regards, Mike I'm +1000 for letting you handle all this build stuff and host it on your server. Copying Johan directly because IIRC the server it is currently on is his and I want to make sure he sees it. Big hooray! for Mike and all his endless work on wicketstuff!! -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [vote] promote 1.5-RC7 to 1.5.0
+1 PS - Sent from a tablet. Please excuse typos, spelling and compiler errors. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org On 2011 8 29 16:40, Igor Vaynberg igor.vaynb...@gmail.com wrote: this vote is to promote 1.5-RC7 to 1.5.0. current bug fixes already made to trunk will be part of 1.5.1 this vote ends Thursday, September 1st at 2pm GMT-7 -igor
Re: Externalized Page Flow in Wicket
Clint, We (Wicket devs and community) are always happy to see new developers and development teams (especially) show interest in contributing back to the Wicket community. On behalf of both, welcome! As all developers understand, maintaining code is much more costly than initially developing it. Especially is this true with framework code like Wicket. It must be very robust and fit so many individual needs of different users. Maintaining code written by others is doubly hard. For that reason, for any wicket-* integration projects as well as other large Wicket plugins / add-ons, we like to see the code incubate on its own before considering the merit of it entering the Wicket codebase. Once it enters the Wicket codebase, we then have to maintain it ad infinitum. If your project gains widespread adoption within the community, and there is a developer base that is willing to support it, we may later pull it into the core codebase. Although Wicket Stuff is a viable option for contributing this code, if you would like more control over the project, you may also want to consider creating a GitHub account for your team or company. You could create the project there, and easily add contributors, manage contributions, etc. Google Code or Sourceforge.net are other options. As one last point, there is a little bit of paperwork required to take any large contribution of code into any Apache Software Foundation codebase. See the two subheadings here: http://www.apache.org/licenses/#clas(Contributor License Agreements and Software Grants). -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Wed, May 11, 2011 at 1:35 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, I think it will be better to put it in wicketstuff/core for the beginning. We are kinda conservative to accept more code to support officially. We don't have much resources anyway. And I don't remember someone else to ask for such flow so maybe it is not that common needed functionality. But if the project gain more popularity, who knows - one day it may become part of the Apache Wicket project. On Wed, May 11, 2011 at 6:26 PM, Checketts, Clint clint.checke...@usaa.com wrote: Wicket Devs, As part of a rollout of Wicket, we had a requirement to externalize the page flow from the Java code. As the result of that effort we created an integration layer for Wicket to work with Spring Web Flow ( http://www.springsource.org/webflow ) Now I'd like to open source that layer and contribute it back to the Wicket project. What are your thoughts? After you all have viewed the code and agree with the overall design (and unit tests), I could see the code being a new separate module like the wicket-spring one is, ie wicket-spring-web-flow. Thanks, -Clint Checketts -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: [Wicketstuff 1.5] Code formatting
I agree - commit-hook-based formatting would be awful, for several reasons: 1 - formatting CAN break code (I know it doesn't usually, but can), but besides that, if I commit, what I worked on should be transmitted to the server and stored in the history - not some mutated version 2 - the statement that everyone can format how he or she likes is FALSE. If I check-in my 16-char tabulation file and you check in your 2-tab-per-tab-tabulation file, and both are transformed to three-spaces-two-commas-and-a-pipe formatting (yes, I'm making that stuff up) when I check out my file, I get the re-formatted version, and so does two-tab guy. So NEITHER of us is working with the same format we like / checked in. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Thu, Apr 7, 2011 at 2:16 PM, Martin Grigorov mgrigo...@apache.orgwrote: Are you sure ? I have never used something like this but it sounds bad. I commit something and then when I open the logs I see something different (my change + some formatting). This way the history is totally messed up. On Thu, Apr 7, 2011 at 6:19 PM, Peter Ertl pe...@gmx.org wrote: +1 on commit-hook-based code formatting Am 07.04.2011 um 18:06 schrieb Hans Lesmeister 2: Martin Grigorov-4 wrote: On Thu, Apr 7, 2011 at 3:51 PM, Hans Lesmeister 2 hans.lesmeis...@lessy-software.de wrote: IMHO Formatting should be done on commit. I guess you don't follow your colleagues work using email notifications. I am not sure if I know what you mean by that. With on commit I meant on the server, in this case the Git-Server. That way everybody can format the way he or she likes. - -- Regards, Hans http://cantaa.de -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicketstuff-1-5-Code-formatting-tp3432552p3433858.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com. -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: ResourceNameIterator for Mobile devices
I didn't read your post in detail, but why not use the file extension as the
mobile attribute? Unless you're planning on serving the same resources as
both xml and html to the iphone device, etc. Just an idea - not fully
fleshed out
On Mon, Mar 28, 2011 at 6:05 PM, Bruno Borges bruno.bor...@gmail.comwrote:
So this is what I have for now.
class MobileStreamLocator extends ResourceStreamLocator implements
IResourceStreamLocator {
public IResourceStream locate(final Class? clazz, String path, final
String style, final Locale locale,
final String extension) {
StringBuilder newExtensions = new StringBuilder();
newExtensions.append(extension);
// Are we running on a device mobile?
if (Session.get() instanceof MobileSession) {
MobileSession ms = (MobileSession) Session.get();
if (ms.isMobileSessionActive()) {
newExtensions = new StringBuilder();
String device = ms.getDeviceId();
if (device != null) {
newExtensions.append(device + . + extension).append(,);
}
newExtensions.append(ms.getFallbackDeviceId() + . +
extension).append(,);
newExtensions.append(extension);
}
}
return super.locate(clazz, path, style, locale, newExtensions.toString());
}
}
What this does is to try the following names:
1a. path_style_locale.mobile.extension
1b. path_style_locale.fallback.extension
1c. path_style_locale.extension
2a. path_locale.mobile.extension
2b. path_locale.fallback.extension
2c. path_locale.extension
3a. path_style.mobile.extension
3b. path_style.fallback.extension
3c. path_style.extension
4a. path.mobile.extension
4b. path.fallback.extension
4c. path.extension
Where mobile can be something like android, iphone, blackberry, and
fallback can be something like m (for... duh... generic mobile).
What do you guys think of this?
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld
On Mon, Mar 28, 2011 at 4:55 PM, Bruno Borges bruno.bor...@gmail.com
wrote:
I'm playing with Wurfl and mobile development on Wicket now and I was
looking at ResourceNameIterator.
It seems to be the best place to have an extended version of the resource
stream locator algorithm.
What I want to do is to get this:
1. path_style_locale_mobile.extension
2. path_locale_mobile.extension
3. path_style_mobile.extension
4. path_style_locale.extension
5. path_mobile.extension
6. path_locale.extension
7. path_style.extension
8. path.extension
Where mobile is a mobile device based on Wurfl XML.
Would also be a great contribution to Wicket's core this stream locator
pattern.
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Time for Wicket 1.5-RC3?
On Mon, Mar 21, 2011 at 7:57 AM, Andrea Del Bene adelb...@ciseonweb.itwrote: Hi, I was just wondering if the next RC has been already planned for the next few days. Recently some bugs that are important to me have been fixed and I'd like to have an updated build. If RC 3 is not planned I will use snapshot jars. I can guarantee it won't be in the next few days. A release has to be voted on for three days after being built. Then it takes nearly 24 hours to hit the mirrors. So, even if someone started right now, it'd be at least four days until it was ready. Stick with the snapshots for now. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Usage of Session
Maybe he means this line:
On Thu, Feb 24, 2011 at 2:42 AM, Martin Grigorov mgrigo...@apache.org
wrote:
- final IPageManager pageManager = getSession().getPageManager();
Which in his patch, he changed to this:
On Thu, Feb 24, 2011 at 2:42 AM, Martin Grigorov mgrigo...@apache.org
wrote:
+ final IPageManager pageManager = getApplication().getPageManager();
If that method weren't final on Session, I would guess that is there so that
you could potentially override the page manager on a per-session basis.
On Thu, Feb 24, 2011 at 3:13 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
On Thu, Feb 24, 2011 at 12:42 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi,
While working on https://issues.apache.org/jira/browse/WICKET-3477 I
found
this usages of Session:
Index: wicket-core/src/main/java/org/apache/wicket/Application.java
===
--- wicket-core/src/main/java/org/apache/wicket/Application.java
(revision
1073297)
+++ wicket-core/src/main/java/org/apache/wicket/Application.java (working
copy)
@@ -273,13 +273,14 @@
{
final Class? extends Component cl = component.getClass();
// If component instantiation is not authorized
- if
(!Session.get().getAuthorizationStrategy().isInstantiationAuthorized(cl))
- {
+ if
(!getSecuritySettings().getAuthorizationStrategy().isInstantiationAuthorized(cl))
// then call any unauthorized component instantiation
// listener
getSecuritySettings().getUnauthorizedComponentInstantiationListener()
.onUnauthorizedInstantiation(component);
}
});
}
Index: wicket-core/src/main/java/org/apache/wicket/Page.java
===
--- wicket-core/src/main/java/org/apache/wicket/Page.java (revision
1073297)
+++ wicket-core/src/main/java/org/apache/wicket/Page.java (working copy)
@@ -33,7 +33,6 @@
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.resolver.IComponentResolver;
import org.apache.wicket.model.IModel;
-import org.apache.wicket.page.IManageablePage;
import org.apache.wicket.page.IPageManager;
import org.apache.wicket.pageStore.IPageStore;
import org.apache.wicket.request.component.IRequestablePage;
@@ -364,7 +360,7 @@
return;
}
- final IPageManager pageManager = getSession().getPageManager();
+ final IPageManager pageManager = getApplication().getPageManager();
if (!getFlag(FLAG_IS_DIRTY) isVersioned()
pageManager.supportsVersioning())
{
setFlag(FLAG_IS_DIRTY, true);
Is it really needed this indirection to get the Application thru the
Session
?
what do you mean get application through session?
-igor
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [vote] release wicket 1.4.16
+1 On Tue, Feb 22, 2011 at 10:30 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: +1 -igor On Sun, Feb 20, 2011 at 8:33 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: This vote is to release wicket 1.4.16. This is a bugfix release on the 1.4.x (stable) branch. Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.16/ Artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.16/dist Maven repo: https://repository.apache.org/content/repositories/orgapachewicket-031/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12316020 This vote ends Wednesday, February 23rd at 9:00am (GMT-8) Please test the release and offer your vote. -igor -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Spring Annotations supoprt for IoC on WebPages
On Tue, Feb 22, 2011 at 4:10 PM, Bruno Borges bruno.bor...@gmail.comwrote:
If enough documentation is supplied, to state that usage of such
annotations
can only be used this way:
class MyPage extends WebPage {
@Autowired
private transient MyService service;
}
People don't read documentation :)
Annotations like @Configured (at type level of panels, pages and components
in general) and @Component would be ignored (or reported).
Is this feature still inviable?
Most of the places I use services are in my IDataProvider and IModel
implementations. For that, you need the proxy. Why muddy the waters with
one way for components and one way for non-components?
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Reducing JIRA spam
I agree with Martin - I've fixed several, especially while releases are being voted on, so the current unreleased version is actually already closed, and new things should go in the next one, but someone puts it in the one that is being voted on. On Mon, Feb 21, 2011 at 11:44 AM, Martin Grigorov mgrigo...@apache.orgwrote: On Tue, Feb 8, 2011 at 12:58 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: It appears that we can reduce the amount of spam JIRA sends to our commits list by telling it not to send notifications when the fix-in version is modified. I'd like that feature to be enabled... I'm -0. sometimes we make mistakes by setting this property to wrong version. Today I fixed one of those. Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: 1.4.16 - adding methods to IBehavior
I suppose it could, although I hadn't really thought about that part of it. I'm not sure that would be a wise idea, but we're not blocking it that I know of. On Sun, Feb 20, 2011 at 10:45 PM, Clint Checketts checke...@gmail.comwrote: So in theory a behavior implementing this could add additional components to the page? Or is the hierarchy frozen at this point? On Friday, February 18, 2011, Jeremy Thomerson jer...@wickettraining.com wrote: What does everyone think about the following patch [1] to add two methods to IBehavior? Obviously, it's not added directly to IBehavior since that would be a breaking API change. It's added to a sub-interface that can optionally be implemented by IBehaviors and is implemented by AbstractBehavior by default. It's for the purpose of allowing behaviors to contribute to things like the visibility and enabled status of a component, which they can't currently do in beforeRender because that happens during the render cycle, at which time such changes are not allowed. [1] - http://mysticpaste.com/view/8231 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
1.4.16 - adding methods to IBehavior
What does everyone think about the following patch [1] to add two methods to IBehavior? Obviously, it's not added directly to IBehavior since that would be a breaking API change. It's added to a sub-interface that can optionally be implemented by IBehaviors and is implemented by AbstractBehavior by default. It's for the purpose of allowing behaviors to contribute to things like the visibility and enabled status of a component, which they can't currently do in beforeRender because that happens during the render cycle, at which time such changes are not allowed. [1] - http://mysticpaste.com/view/8231 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
WicketTester#assertInvisible
I just ran across this nuance this week If you have this: wicket:enclosure child=comp1 div wicket:id=comp1/div div wicket:id=comp2/div /wicket:enclosure Now, say comp1 is invisible, so the whole enclosure is invisible. Now, in WicketTester, if you test assertInvisible(comp2), it will fail because technically comp2 *is* visible itself, but it's not really visible because its parent is not visible. So, I want to fix this. My question for the group is, which should I do: 1 - change assertInvisible to test that it is truly visible (i.e., in hierarchy)? 2 - add a new method, assertInvisibleInHierarchy that tests for actual visibility and add to the javadoc for assertInvisible that it only tests the actual component's visibility, and not its true visibility (as in, in the hierarchy)? -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: WicketTester#assertInvisible
On Sun, Feb 13, 2011 at 11:46 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
This is a fundamental dilemma ;) Also on implementation side somebody
may implement:
1)
isvisible() {
return super.isvisible() businesslogic.isvisible();
}
or simply
2)
isvisible() {
return businesslogic.isvisible();
}
So if 2) is allowed and recommended, then isvisible is really only
businesslogic test instead of real visibilty check.
Yeah, but that's in the component itself - which means that the business
logic check IS the visibility determining factor. Wicket will call
isVisible, and it won't appear because of your business logic. You just
disabled people from calling setVisible(false) and also hiding it.
But, I'm asking more about WicketTester and related components that aren't
visible because something in the hierarchy above them is not visible - in
this case an enclosure. I haven't looked at the exact implementation of
WicketTester, but I think we should change the logic to pass assertInvisible
if the component's isVisible method returns true, but some parent of the
component (an enclosure, etc) is not visible, since in all reality, the
component is then also invisible.
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: WicketTester#assertInvisible
On Sun, Feb 13, 2011 at 1:32 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
I haven't looked at the exact implementation of
WicketTester, but I think we should change the logic to pass
assertInvisible
if the component's isVisible method returns true, but some parent of the
component (an enclosure, etc) is not visible, since in all reality, the
component is then also invisible.
It is like that already:
public Result isVisible(String path)
{
Component component = getLastRenderedPage().get(path);
if (component == null)
{
fail(path: ' + path + ' does no exist for page:
+
Classes.simpleName(getLastRenderedPage().getClass()));
}
return isTrue(component ' + path + ' is not visible,
component.isVisibleInHierarchy());
}
Well, it doesn't work in the scenario I had, which may be specific to
enclosures. I'll get my quickstart uploaded to a JIRA and fix it at some
point.
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Can't remember: way to add properties files for validators?
Someone asked today, and I can't remember I think the answer is no. Is there a way to add a properties file with messages for a validator? In other words, could we package a jar of validators with their messages to be reused by folks? -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Can't remember: way to add properties files for validators?
Hmm just tried it in 1.4 and it worked in one example, and not in another. I'll look at it more tonight when I'm through with this training class and add a JIRA if it has a bug. Thanks! -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Thu, Feb 10, 2011 at 12:30 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: yes. added in both 1.4 and 1.5 i think. MyValidator.properties next to MyValidator.class -igor On Thu, Feb 10, 2011 at 9:58 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Someone asked today, and I can't remember I think the answer is no. Is there a way to add a properties file with messages for a validator? In other words, could we package a jar of validators with their messages to be reused by folks? -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Where are 1.4-snapshot jars automatically built now?
Wicketstuff repo only has from last June. Where are the current snapshots? I just realized that my quickstart was pulling from old jars that don't even have onConfigure. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Where are 1.4-snapshot jars automatically built now?
Ah, thanks. I think we should probably add that as a repo for our quickstart. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Fri, Feb 11, 2011 at 12:38 AM, Attila Király kiralyattila...@gmail.comwrote: This one gets 1.4 and 1.5 snapshots regularly from somewhere: https://repository.apache.org/content/repositories/snapshots/org/apache/wicket/ https://repository.apache.org/content/repositories/snapshots/org/apache/wicket/ 2011/2/10 Igor Vaynberg igor.vaynb...@gmail.com i wonder if hudson is publishing them somewhere... -igor On Thu, Feb 10, 2011 at 12:17 PM, Jeremy Thomerson jer...@wickettraining.com wrote: Wicketstuff repo only has from last June. Where are the current snapshots? I just realized that my quickstart was pulling from old jars that don't even have onConfigure. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 4:41 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 4:40 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: what if we factor out html packages out of core? core wont have a dependency on them. then all people will have to change from wicket-core to wicket-html. the wicket module serves as a standard wicket profile which is everything you need to run on a servlet container and build web apps. Gotcha. So, please cast a vote (this is not an official vote thread, but I want to get the feelings on this) for one of the following two methods of handling this: [ ] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. [ ] - Make an aggregated jar for classes, one for sources, and one for javadocs. This means that people can accidentally end up in classpath nightmares by having multiple duplicate classes on their classpath. It helps non-Maven users by making a single jar download. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* I'm +1 for this one: [+1] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. It seems so far that most are in agreement with this. I tried to do this briefly tonight, but apparently my Maven foo isn't high enough. If anyone wants to try it out, feel free. You can see a diff of what I tried at [1]. I tried several variations, but I think I have a core problem with the approach. Basically, I figured that I could make the wicket module a pom-only project that listed a dependency on -core. Later, a dependency on -html could exist if that were created. -core brings with it -util and -request. Then, I changed all other modules that were depending on -core to depend on plain wicket. But, that didn't work. They kept looking for wicket.jar, even though I wasn't building a jar. I tried several variations of making it a pom-only project, but perhaps this approach won't work at all. I haven't ever tried this sort of thing before with Maven. Feel free to give me a tip, or a working patch :) [1] - http://mysticpaste.com/view/4881/text (trying out Lombardi's paste tool you need a unified diff colorizer :) -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Tue, Jan 25, 2011 at 7:06 AM, James Carman ja...@carmanconsulting.comwrote: It sounds like you've fixed some of the problem(s) that caused you to split stuff up in the first place, but you did it using *code design* which is the correct way to go about this. The module gymnastics approach just leads to confusion, IMHO. The separate modules is a good way to enforce the separation. If you have other ideas for enforcing them, I'd be happy to hear them. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Do Lucene developers use FindBugs?
I think it was a form letter he's sending out. The body of the message says Wicket -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Mon, Jan 24, 2011 at 10:38 AM, James Carman ja...@carmanconsulting.comwrote: So, what does this have to do with Lucene? 2011/1/24 César Couto cesar...@dcc.ufmg.br: Dear developers, I am a PhD student at UFMG, Brazil and as part of my research I am making a study about the relevance of the warnings reported by the FindBugs bug finding tool. Since I am planning to use Wicket as a subject system in my research, I would like to know if Wicket's developers usually run FindBugs as part of the system development process. Thanks in advance, Cesar Couto -- http://www.decom.cefetmg.br/cesar
[discuss] How to resolve wicket aggregate classes / sources jar issues
There are two issues [1] and [2] that deal with 1.5-RC1 having an aggregate jar for the wicket-core, wicket-request, and wicket-util classes, but not having an aggregate of the sources. Martin graciously assigned it to me, but I want to discuss it with the community to figure out how we should resolve it. First, some background (hopefully I'm remembering it all correctly) What was all previously in the wicket subfolder was split into wicket / wicket-core / wicket-util in the early development of 1.5. I don't know why - can someone comment on why? I don't think it could possibly give us that much benefit or be *that much* cleaner. But, maybe it is. Then, to avoid confusion for those who previously depended on wicket.jar (which now is missing all -util and -request classes), the wicket subfolder was renamed to wicket-core, and wicket.jar was built as an aggregate of wicket-core, wicket-util, and wicket-request. This was really just done for non-Maven users so that they could get all the core Wicket dependencies in one jar rather than three. Problems: 1 - if you use Maven, you should just depend on wicket-core, which will depend on the others. But, if you incorrectly depend on wicket.jar, and wicket-auth-roles or extensions, etc, you end up with duplicated classes because you'll have wicket.jar and the three independent jars. 2 - If you don't use Maven, you can just use wicket.jar, but we're not building wicket-sources.jar (or it's built empty), so you can't really attach sources in your IDE. Solutions: 1 - Martin suggests that we don't deploy wicket.jar to maven repos because it's not intended for maven users. I agree with this, but it doesn't fix all the problems above 2 - We could somehow build wicket-sources (and wicket-javadocs) jar files. These should be deployed wherever wicket.jar is, but like #1 mentions, none should go to Maven repos. 3 - Combine all three projects back into one. All these problems are solved instantly. 4 - Don't build the aggregated jar(s) at all. Really, I'd opt for #3. I don't think we need all three separate projects. I don't see a benefit. If we must keep the three separate code modules, then I opt for #4. I don't like the idea of deploying multiple artifacts with the same stuff in them. It's too easy for folks to end up with duplicated classes in their classpath. We don't want to contribute to that. Whatever we decide, I feel that if we build wicket.jar (aggregated classes), we *must* build a sources and javadocs jar. Input? [1] - https://issues.apache.org/jira/browse/WICKET-3365 [2] - https://issues.apache.org/jira/browse/WICKET-3376 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 11:32 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: the reason for split was to enforce good code practices. over time as more and more people work on wicket the code has become a mess. for example, application threadlocal lookups everywhere - with the new structure those are out of request processing pipeline. there were a lot of interpackage dependencies that simply didnt make sense, it made unit testing hell Okay, that makes good sense. I didn't remember a discussion of why it was done - but I could have missed that discussion. I think it happened around the time I was out of the country for a couple months, so I was several hundred email threads behind :) In that case, if we want to keep the aggregated jar for non-Maven users, we need to: 1 - build an aggregate sources / javadocs as well 2 - not deploy the aggregates to Maven so that nobody can accidentally end up depending on both Agreed? -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Renaming IInitializer?
On Mon, Jan 24, 2011 at 11:51 AM, Eelco Hillenius eelco.hillen...@gmail.com wrote: Doesn't solve anything in particular, right? Personally, I think the current names are fine. We've always opted for specific, descriptive names, even when grossly verbose :) I, too, think we should rename it. I like the approach of moving it to an interface that extends IInitializer, deprecate and remove in 1.6. Although, I feel like a 1.5 name change would be absolutely fine - even with an RC out. It's a simple find/replace - not a complicated change. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 11:50 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: have the wicket module not create an aggregate jar, just list all the dependencies. Then we don't need the wicket module at all, right? Or I'm misunderstanding what you mean by list all the dependencies - which I assume to mean document the jars you need somewhere. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 12:43 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 12:36 PM, Martin Grigorov mgrigo...@apache.orgwrote: Let's think now what problems would cause making -extentions (and all other except -util and -request) depending on wicket.jar IMHO, we do *not* want wicket.jar to even be available in Maven. The aggregate jar should be only for those who do not use Maven. Those who use it should just change from wicket to wicket-core when they upgrade versions and everything will continue to work. Should have mentioned the reason again for this: to avoid the possibility of Maven users having duplicate classes in the classpath. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 12:47 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: we should have the aggregate module explained for the reason in mine and martijn's emails. we should simply change it so it doesnt deploy any artifacts, just a pom. I disagree. Why go through the trouble of creating a fake aggregate module just so someone doesn't have to type five characters in their pom when upgrading a major version? When they change 1.4.16 in their POM to 1.5.0, they can also type -core at the end of their wicket dependency. Done. No maintenance on our side. non-maven users will have to figure it out. I'm fine with this - they're used to it. I think they must like the pain. :) So, in summary: my opinion is that we just remove the aggregate module and move on with real development. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: what if we factor out html packages out of core? core wont have a dependency on them. then all people will have to change from wicket-core to wicket-html. the wicket module serves as a standard wicket profile which is everything you need to run on a servlet container and build web apps. Gotcha. So, please cast a vote (this is not an official vote thread, but I want to get the feelings on this) for one of the following two methods of handling this: [ ] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. [ ] - Make an aggregated jar for classes, one for sources, and one for javadocs. This means that people can accidentally end up in classpath nightmares by having multiple duplicate classes on their classpath. It helps non-Maven users by making a single jar download. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 4:40 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: what if we factor out html packages out of core? core wont have a dependency on them. then all people will have to change from wicket-core to wicket-html. the wicket module serves as a standard wicket profile which is everything you need to run on a servlet container and build web apps. Gotcha. So, please cast a vote (this is not an official vote thread, but I want to get the feelings on this) for one of the following two methods of handling this: [ ] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. [ ] - Make an aggregated jar for classes, one for sources, and one for javadocs. This means that people can accidentally end up in classpath nightmares by having multiple duplicate classes on their classpath. It helps non-Maven users by making a single jar download. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* I'm +1 for this one: [+1] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [vote] retry: release wicket 1.5-rc1
+1 to release On Fri, Jan 21, 2011 at 4:10 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: +1 to release -igor On Tue, Jan 18, 2011 at 10:16 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: this is the second vote to release wicket 1.5-rc1. all vote-blocking issues previously reported have been fixed branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-RC1 artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-RC1/ maven repo: https://repository.apache.org/content/repositories/orgapachewicket-044/ changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310561fixfor=12315483sorter/field=issuekeysorter/order=DESC this vote ends Friday, January 21 at 10:00am GMT-8 please test the release and offer your vote cheers, -igor -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: How to streamline ajax page region toggle
On Thu, Jan 20, 2011 at 1:51 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
interesting idea. i think this would require a bit of a trick.
a) modify enclosure tag handler to accept an attribute instead of a tag
b) modify enclosure tag handler to add a bit of metadata to the
component marking that it belongs to an enclosure
c) add a ajaxrequesttarget.listener to the request target that checks
for this bit of metadata and adds the enclosure container to the ajax
request target.
not sure how feasible this all is because the enclosure container is
an auto component. but, you are welcome to tinker around.
-igor
I, too, like the idea. Couldn't it be simpler? Couldn't he:
1: Override newAjaxRequestTarget in WebApplication
2: When he creates an ART, add a listener to it.
3: In the listener, in onBeforeRespond, do this:
for(Component component : map.values()) {
Enclosure parentEnclosure = component.findParent(Enclosure.class);
while (parentEnclosure != null) {
Enclosure topParent = parentEnclosure.findParent(Enclosure.class);
if (topParent != null) {
parentEnclosure = topParent;
}
}
if (parentEnclosure != null) {
addComponent(parentEnclosure);
}
}
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: svn commit: r1060043 - in /wicket/common/site/trunk: _site/start/quickstart.html start/quickstart.md
This fixed the 1.5-SNAPSHOT quickstart problem- thanks! On Mon, Jan 17, 2011 at 12:54 PM, mgrigo...@apache.org wrote: Author: mgrigorov Date: Mon Jan 17 18:54:55 2011 New Revision: 1060043 URL: http://svn.apache.org/viewvc?rev=1060043view=rev Log: Use Apache Nexus repo for -SNAPSHOT versions of the quickstart Modified: wicket/common/site/trunk/_site/start/quickstart.html wicket/common/site/trunk/start/quickstart.md Modified: wicket/common/site/trunk/_site/start/quickstart.html URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/start/quickstart.html?rev=1060043r1=1060042r2=1060043view=diff == --- wicket/common/site/trunk/_site/start/quickstart.html (original) +++ wicket/common/site/trunk/_site/start/quickstart.html Mon Jan 17 18:54:55 2011 @@ -177,7 +177,7 @@ else cmd = 'mvn archetype:generate -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=' + version + ' -DgroupId=' + groupId + ' -DartifactId=' + artifactId; - if (version.match(/.*SNAPSHOT/)) cmd += ' -DarchetypeRepository=http://wicketstuff.org/maven/repository/'; + if (version.match(/.*SNAPSHOT/)) cmd += ' -DarchetypeRepository= https://repository.apache.org/content/repositories/snapshots/'; cmd += ' -DinteractiveMode=false'; document.getElementById(cmdLine).value = cmd; } Modified: wicket/common/site/trunk/start/quickstart.md URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/start/quickstart.md?rev=1060043r1=1060042r2=1060043view=diff == --- wicket/common/site/trunk/start/quickstart.md (original) +++ wicket/common/site/trunk/start/quickstart.md Mon Jan 17 18:54:55 2011 @@ -52,7 +52,7 @@ typing in the groupId, artifactId and ve else cmd = 'mvn archetype:generate -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=' + version + ' -DgroupId=' + groupId + ' -DartifactId=' + artifactId; - if (version.match(/.*SNAPSHOT/)) cmd += ' -DarchetypeRepository=http://wicketstuff.org/maven/repository/'; + if (version.match(/.*SNAPSHOT/)) cmd += ' -DarchetypeRepository= https://repository.apache.org/content/repositories/snapshots/'; cmd += ' -DinteractiveMode=false'; document.getElementById(cmdLine).value = cmd; } -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Jetty 7 iff servlet-api 2.5
I'm cool with it. On Mon, Jan 17, 2011 at 3:58 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: https://issues.apache.org/jira/browse/WICKET-3344 On Mon, Jan 17, 2011 at 10:29 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: I just migrated our examples code to jetty 7 and it requires servlet-api 2.5 to run. Any objections? Servlet api 2.3 is really not an option anymore, 2.4 doesn't give us much, and 2.5 has been out since 2007. Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Display component feedback message once: safety net renders them always before
On Sat, Jan 15, 2011 at 4:17 AM, Leszek Gawron lgaw...@apache.org wrote: Jeremy, On 2011-01-14 03:57, Jeremy Thomerson wrote: I had encountered this issue and for one of my training classes, I threw together a solution. Your post prodded me to go ahead and post my solution as a blog post. After dusting off my long-forgotten blog, here it is: http://www.jeremythomerson.com/blog/2011/01/catching-all-feedback -messages-that-arent-rendered-by-other-feedback-panels/ (or http://bit.ly/eHUEuN if that gets chopped up). Your solution is quite nice but I have a request: you use ComponentFeedbackMessageFilter. What if I wanted your functionality in some component only - not whole page - using ContainerFeedbackMessageFilter. Example: instead of yours: // create the form above form.add(new FeedbackPanel(feedback, new ComponentFeedbackMessageFilter(form))); final TextField name = new TextField(name, new PropertyModel(productModel, name)); name.setRequired(true); form.add(new FeedbackPanel(nameFeedback, new ComponentFeedbackMessageFilter(name))); form.add(name); final TextField price = new TextField(price, new PropertyModel(productModel, price)); price.setRequired(true); price.add(new MinimumValidator(0d)); form.add(new FeedbackPanel(priceFeedback, new ComponentFeedbackMessageFilter(price))); form.add(price); I would love: // create the form above form.add(new FeedbackPanel(feedback, new RenderOnlyWhatMyChildrenMissedFeedbackMessageFilter(form))); [1] final TextField name = new TextField(name, new PropertyModel(productModel, name)); name.setRequired(true); form.add(new FeedbackPanel(nameFeedback, new ComponentFeedbackMessageFilter(name))); form.add(name); final TextField price = new TextField(price, new PropertyModel(productModel, price)); price.setRequired(true); price.add(new MinimumValidator(0d)); form.add(new FeedbackPanel(priceFeedback, new ComponentFeedbackMessageFilter(price))); ^6 remove this line. form.add(price); This way nameFeedback renders messages for name component feedback renders messages for price and other components left without own feedback panel but NOT from name as those messages would be rendered twice. All we need is a slight modification of AllExceptFeedbackFilter that would take a root component instead of assuming page instance. You code from example then could look something like; // create the form above final TextField name = new TextField(name, new PropertyModel(productModel, name)); name.setRequired(true); form.add(new FeedbackPanel(nameFeedback, new ComponentFeedbackMessageFilter(name))); form.add(name); final TextField price = new TextField(price, new PropertyModel(productModel, price)); price.setRequired(true); price.add(new MinimumValidator(0d)); form.add(price); form.add(new FeedbackPanel(feedback, new AllExceptFeedbackFilter(form))); hope you like the idea. -- Leszek Gawron http://lgawron.blogspot.com Leszek, I *do* like the idea. I will implement it this way when I add it to core. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: onError missing from SubmitLink
On Fri, Jan 14, 2011 at 2:22 PM, Martin Grigorov mgrigo...@apache.orgwrote: Since it is API change it can be ported to 1.4 Assuming he meant s/can/can't/ here. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Display component feedback message once: safety net renders them always before
On Tue, Jan 4, 2011 at 10:13 AM, Jeremy Thomerson jer...@wickettraining.com wrote: I had encountered this issue and for one of my training classes, I threw together a solution. Your post prodded me to go ahead and post my solution as a blog post. After dusting off my long-forgotten blog, here it is: http://www.jeremythomerson.com/blog/2011/01/catching-all-feedback -messages-that-arent-rendered-by-other-feedback-panels/ (or http://bit.ly/eHUEuN if that gets chopped up). Moving this discussion to dev@ - does anyone think that I should commit this catch all feedback panel to core? Would it be useful to others? I've used it, or something similar in several applications - not sure if others have had similar requirements. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Display component feedback message once: safety net renders them always before
Nah - it could throw an IFoundMyTwinException - except the leading I might make someone think that it was an interface! On Thu, Jan 13, 2011 at 8:26 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: if you put two of them on a page do you get an infinite loop? :) -igor On Thu, Jan 13, 2011 at 12:19 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Tue, Jan 4, 2011 at 10:13 AM, Jeremy Thomerson jer...@wickettraining.com wrote: I had encountered this issue and for one of my training classes, I threw together a solution. Your post prodded me to go ahead and post my solution as a blog post. After dusting off my long-forgotten blog, here it is: http://www.jeremythomerson.com/blog/2011/01/catching-all-feedback -messages-that-arent-rendered-by-other-feedback-panels/ (or http://bit.ly/eHUEuN if that gets chopped up). Moving this discussion to dev@ - does anyone think that I should commit this catch all feedback panel to core? Would it be useful to others? I've used it, or something similar in several applications - not sure if others have had similar requirements. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Fragility/Stability of Wicket core
On Sat, Jan 8, 2011 at 7:03 PM, richard emberson richard.ember...@gmail.com
wrote:
Ok, you need to debug whats in a Model when it is added to
a Component. So, in setModelImpl which is called by the
Component constructor you add code to get the object
out of the Model (if its not null, of course) by calling
model.getObject():
void setModelImpl(IModel? model)
{
if (model != null) {
System.out.println(Component.setModelImpl: model.object=+
model.getObject());
}
.
}
Well, just adding this simple code causes a JUnit test to fail.
(And, if you added this debugging a couple of editing cycle prior
to running all the tests, you've got the problem of even knowing
that this is the offending code.)
Why? Give up.
Its because in a Component's constructor the Component has not
yet been added to its parent Component. Thus, the Component's
path only has it as a member. Which means that if the Model
was a ResourceModel, which BTW is wrapped!!!, calling getObject
gets the wrong path for the resource, the resource lookup
fails, and the world ends.
For most folk this is never a problem, even for most developers
because they are making changes to a working Wicket core.
But for me, on the other hand, porting it to Scala where only
bits and pieces worked originally, I ran into this kind of
hidden side effect well, it seemed like all the time, but
it was once and a while ... but it take time to figure out the
issue.
Anyway, amazing that simply asking a model for its inner object
can end the world if you do it at the wrong place.
Ok, all software is fragile like this - one thing wrong that
bang - but it took an hour to find the little innocuous bit of
code.
Not all that amazing. This is happening *during construction* which always
leaves objects in fragile states. It's assumed that you can't start
monkeying around with an object's state until construction is completed (and
not expect side effects).
[I actually put code, kind of like a constraint, in setModelImpl
to make sure that any model added never had, as an object,
an Option: Some(value) or None; looking for a totally unrelated bug.]
I feel better now, thank you for your time and patience.
Richard
I agree with what others on your scala thread said:
1 - If you want a Scala framework *like* Wicket, start writing Scala code
from the ground up with ideas taken from Wicket. Some code could perhaps be
ported over in small pieces. But not large sections (or the whole thing
like you're trying).
2 - If you want to use Wicket *in Scala*, work on a transparent layer that
sits on top of stock Wicket and adds nice features that would be useful to
the Scala crowd.
You have said that your goal is to port java developers to Scala. I'm
interested in trying Scala at some point. I would try either option one or
two above I would prefer two. With it, I get to keep my Wicket
expertise and incrementally add *new hotness* from Scala. I am very
unlikely to try a modified port such as the one you are trying to do. It's
learning a whole new thing all at once, with annoying similarities to
something I know, but inconsistencies that I wouldn't expect.
In my book, 2 is your best bet.
(only my $0.02 in a declining economy)
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: more explicit handling of null values - yay or nay?
On Wed, Jan 5, 2011 at 11:44 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: ive recently ran into a few cases where while implementing ajaxfallbacklink i forgot to test the passed in request target for null, causing NPEs when the app was accessed from browsers where ajax failed for whatever reason. with all this talk of scala recently i figured why not try and translate one of the feature i really like in scala Option/Null/Some to our code base. i came up with a simple value class: https://gist.github.com/c38456ee75fed541c932 and changed the ajaxfallbacklink to use it https://gist.github.com/2f648c7feacacf18fc40 the cascade from this change was pretty impressive, a lot of places in our code support passing a possibly null request target but make no mention of it: https://gist.github.com/d9933e24c21f061c6ac2 so advantages: makes possible null value handling explicit no more checking the javadoc to see if the method supports null as a parameter value or ever returns a null an api break before 1.5 rc1 i think overall makes lives of wicket users easier disadvantages: a bit wordier code an api break just about when we are ready to release 1.5 m4/rc1 whatever we call it yay or nay? obviously if we say yay there are a lot more places in our code that can benefit from this -igor Someone on the list a while ago asked that we simply have a NoOpAjaxRequestTarget to avoid NPE. Obviously it's not as generic as your option, but it also requires less code changes. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: more explicit handling of null values - yay or nay?
On Wed, Jan 5, 2011 at 12:13 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: We use only Ajax or non-Ajax components. No fallbacks. I think in the (near) future we don't really need fallbacks. Everything is javascript nowdays. Only mammooths are fallback. From that perspective it seems excess to add code to make something nice that is not going to exist for long. Ofcourse the opposite is also true, if we make fallbacks very comfortable and widely supported, people will continue using non-javascript devices longer than necessary. The developers of Wicket won't be influencing whether people use JS or not, and we don't influence the people who make the decisions on whether or not an app needs to support JS / non-JS users. We provide a framework for supporting whatever needs to be supported - within reason. I think that for the short-term, we still will have many apps that need to support both. We just want to know what's the best way to support those developers who have to support both. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: Scala-Wicket Help and Advice
. This would result in many
of the interfaces, the I files, such as IModel.scala,
going away.
Some general refactoring:
As an example, consider factoring out the IModel[T] from
Component. Half the time a user wants a Component with
no model, so, if there was a HasModel trait:
class Model[T](var value: T) {
def getObject: T = value
def setObject(value: T): Unit = this.value = value
}
trait HasModel[T] {
var model: Model[T]
def getDefaultModel: IModel[T] = model
def setDefaultModel(model: IModel[T]): this.type = {
this
}
def getDefaultModelObject: Option[T] = {
}
def setDefaultModelObject(obj: T): this.type = {
this
}
}
The Component hierarchy would have no model support.
The user could add model support when needed:
val form = new Form(hi)
with HasModel[Int] { var model = new Model(42) }
Just an Idea.
STM: There are a number of Scala STM projects and I do not know
if it is useful to add STM capabilities to Scala-Wicket.
RBAC: I've written a Scala implementation of the NIST RBAC
recommended standard and might consider adding it.
Logging: Adding a Scala-based logging framework to aid user
debugging.
Monitoring and stats: In the last couple of years many web
sites have added monitoring and statistics gathering
capabilities (e.g., who clicks what, where, how long, on
what page does the visitor exit the web site, etc.) in
order to know how the web site is being used and then
improve the web site.
Significant Memory Usage Reduction: I've an idea that would
significantly decrease the memory usage of Scala-Wicket and
I plan to do a test implementation.
Replace Java features: There are still some Java-isms that can
be replaced with Scala equivalents.
Port additional Java Wicket libraries to Scala.
Enable multiple instances of a unit tests to be run at once.
More:
I want to avoid using some of the WTF features of Scala (when a
Java programmer looks at the code and says WTF) in order to
ease and accelerate acceptance by Java programmers; as
examples, implicits can make code hard to understand and
advanced Scala type usages, as James Gosling said, makes one's
head spin.
Help and Advice: How should Scala-Wicket be extended and released
Scala-Wicket is a port and evolution of Wicket, not a ground-up
re-write. Given that, what would you do differently in Wicket
now that there are years of experience using it?
How best to get a hosting site, release the code and build a
community?
If you're looking for a place to host it, I'd recommend starting with
Github. Git is where the crowd is headed, and Github is the easiest place
to get up and running with it these days.
You mentioned earlier the idea of it being an Apache project. If you wanted
it to be an Apache project, you would start at the Incubator (
http://incubator.apache.org/). The one barrier you'll have initially is
that Apache favors community over code... so it's not a great place to
start a one-man project. Since this is a port of an existing Apache
project, you might have more leniency, but you'd have to build a community
around the project before you could ever graduate from the incubator.
Probably Github is your best bet for now. Build a community. Then, if your
community is in favor, move to Apache. By that time, ASF might have full
git support.
Are there any mechanism to help fund such an open-source project?
Best bet is to build a community. Of course, if you can find some company
that wants such a project, you can get monetary support to develop /
maintain. But that seems unlikely in this case with the limited number of
companies looking for Scala out there, and especially since this is an
unproven port of a large Java project. So, start by getting folks like
jWeekend involved - great coders who are already salivating for Scala. Find
other individuals such as yourself who are interested, and build a group of
core committers.
This is not meant to be a general announcement but rather a means
for me to get some initial advice as to how to proceed.
Any help is appreciated.
Richard Emberson
I'm impressed. Quite an undertaking.
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: automatically open tags for all Components
On Thu, Dec 30, 2010 at 9:46 AM, Juergen Donnerstag
juergen.donners...@gmail.com wrote:
we have several components which use
�...@override
protected void onComponentTag(final ComponentTag tag)
{
if (tag.isOpenClose())
{
tag.setType(TagType.OPEN);
}
super.onComponentTag(tag);
}
to convert the Component's tag open-close to open-body-close. I wonder
whether we should make this the default. It's usually required anyway
and it shouldn't harm any component (incl input).
-Juergen
-0 - it changes the user's markup for no apparent reason
--
Jeremy Thomerson
http://wickettraining.com
Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: automatically open tags for all Components
On Thu, Dec 30, 2010 at 5:02 PM, Juergen Donnerstag juergen.donners...@gmail.com wrote: right. I didn't mean to apply to 1.4 but 1.5 only Actually, changing my opinion from -0 to -1 (even for 1.5). We only do this on tags that need it now (Label, for example). I believe that's the way it should be. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: wicketst...@github: re-organize now or later?
I agree. Jeremy Thomerson http://wickettraining.com -- sent from my smart phone, so please excuse spelling, formatting, or compiler errors On Dec 29, 2010 11:49 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i think core and sandbox are probably better names and more clearly communicate the intent. -igor On Wed, Dec 29, 2010 at 9:30 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Currently o...
Re: WICKET-3261
I don't think so. Not sure how many use velocity, jmx, or auth roles (vanilla). Doesn't typically make sense to have both spring and guice. Jeremy Thomerson http://wickettraining.com -- sent from my smart phone, so please excuse spelling, formatting, or compiler errors On Dec 26, 2010 2:29 PM, Martin Grigorov mgrigo...@apache.org wrote: after 2 hours running git-svn failed ... pure SVN rename passed for few minutes. Now all is good. do we want wicket-all.jar artifact that will contain wicket, -extensions, -ioc, -guice, -spring, -auth-roles, -datetime, -jmx and -velocity ? This would mean adding a new Maven module that will aggregate those above. I can add it only in the profile for Hudson so it wont slower the build on dev machines On Sun, Dec 26, 2010 at 6:45 PM, Martin Grigorov mgrigo...@apache.org wrote: @devs: please do not commit anything in the next hour or two. In this very moment my git-svn ...
[ANNOUNCE] Wicket 1.4.15 released
The Wicket development team is proud to announce that we have released Wicket 1.4.15. This is a bugfix and minor improvement release in the 1.4.x (stable) branch. To download: http://www.apache.org/dyn/closer.cgi/wicket/1.4.15 Release Tag: http://svn.apache.org/repos/asf/wicket/releases/wicket-1.4.15/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561styleName=Htmlversion=12315900 To use with Maven (the recommended way to use Wicket): dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.4.15/version /dependency -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: [vote] release Wicket 1.4.15
On Mon, Dec 20, 2010 at 2:10 AM, Jeremy Thomerson jer...@wickettraining.com wrote: This vote is to release wicket 1.4.15. This is a bugfix release on the 1.4.x (stable) branch. Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.15/ Artifacts: http://people.apache.org/~jrthomerson/wicket-1.4.15/dist Maven repo: http://people.apache.org/~jrthomerson/wicket-1.4.15/m2-repo Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561styleName=Htmlversion=12315900 This vote ends Thursday, December 23 at 2:30am (US/CST or UTC/GMT -6 hours) Please test the release and offer your vote: [ ] Yes, release [ ] No, don't release it (and please tell us why) -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org The vote passes with 3 binding +1s and one non-binding +1. I'll start the work on making the release official now. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: WICKET-3261
Unfortunately, the part you are objecting to is not a part of this ticket. It was done a long time ago on trunk. This ticket is only about making dependency management easier on the non-maven folks. If you'd rather see all three (now sort of four) modules re-combined, I think it'd be better to start a separate discussion. Jeremy Thomerson http://wickettraining.com -- sent from my smart phone, so please excuse spelling, formatting, or compiler errors On Dec 22, 2010 7:34 AM, James Carman ja...@carmanconsulting.com wrote: -1, sounds very confusing to me. I was just looking for something last night in the source. It was something that I assumed would be in the core of the framework, but I had to look in wicket-util for it. I don't like that. If it's required to run Wicket, then it should be part of the core. On Tue, Dec 21, 2010 at 11:53 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, With http...
Re: Moving wicket stuff to github
On Wed, Dec 22, 2010 at 3:35 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: i started the import here: https://github.com/wicketstuff/wicketstuff -igor I removed everyone from the SF.net project except Igor, Martijn, and myself. I took SVN commit permissions away from the three of us. This should prevent anyone from accidentally committing to the repo now that it is moved. Once I hear from Igor that we are good to go at GH, I'll svn delete * or svn mkdir ALL_CODE_IS_MOVED; svn mv * ALL_CODE_IS_MOVED/ and svn add README_FIRST_WE_HAVE_MOVED_TO_GITHUB.txt. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
[vote] release Wicket 1.4.15
This vote is to release wicket 1.4.15. This is a bugfix release on the 1.4.x (stable) branch. Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.15/ Artifacts: http://people.apache.org/~jrthomerson/wicket-1.4.15/dist Maven repo: http://people.apache.org/~jrthomerson/wicket-1.4.15/m2-repo Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561styleName=Htmlversion=12315900 This vote ends Thursday, December 23 at 2:30am (US/CST or UTC/GMT -6 hours) Please test the release and offer your vote: [ ] Yes, release [ ] No, don't release it (and please tell us why) -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: Fix version in JIRA
On Mon, Dec 20, 2010 at 1:02 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: there are some that are assigned for 1.6 because we are not fixing them in 1.5. lets not touch those. we need to be able to assign to future versions. i think we can keep things assigned to 1.5.0 for things that need to be fixed before the final comes out and reassign them to milestones as we are fixing them. ie we need to be able to communicate: this issue cannot be fixed in the next minor release - maybe because it breaks api this issue cannot be fixed in the next major release - maybe its outside of scope this issue is scheduled post next major release - starting to create the roadmap so i dont think fix versions are bad, what is bad is that people other then developers can assign them. Can we: 1 - add a field target fix version for the scenarios you describe above and 2 - change it so that only JIRA project admins can assign either field target fix version and fix version I've never used JIRA much on the admin side, so I am not sure what can be done, but those seem like standard requirements. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: [DISCUSS 1.5] Rename IHeaderResponse to IResourceResponse (or similar)?
Will do. It will be a couple of days. On Mon, Dec 20, 2010 at 4:28 PM, Martin Grigorov martin.grigo...@gmail.com wrote: Can you add demo of contribution to the footer in the new example application? Jeremy Thomerson jer...@wickettraining.com wrote: On Sat, Dec 18, 2010 at 8:25 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Sat, Dec 18, 2010 at 2:27 AM, Juergen Donnerstag juergen.donners...@gmail.com wrote: I understand that IHeaderResponse is no longer accurate, but IResourceResponse IMO would simply be wrong: it's not a response to a resource. It contributes to a specific section of a response such as Header or Footer Agreed. I just haven't thought of a great name for it. IAmGoingToRenderYourStuffSomewhereResponse seemed a little unwieldy, and it was the best I had at the time. :) Perhaps IResourceContributions (to replace IHeaderResponse) and IResourceContributor (to replace IHeaderContributor) and contributeResources (to replace renderHead of IHeaderContributor)? Anybody else have an opinion on this? Good ideas for names? Strong feelings to just leave it alone? -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org -- Sent from my mobile phone. Please excuse my brevity. -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
Build 1.5-M4 release tonight?
I'm going to build a 1.4.x release tonight. Should I build a 1.5 release as well? -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: [DISCUSS 1.5] Rename IHeaderResponse to IResourceResponse (or similar)?
On Sat, Dec 18, 2010 at 2:27 AM, Juergen Donnerstag juergen.donners...@gmail.com wrote: I understand that IHeaderResponse is no longer accurate, but IResourceResponse IMO would simply be wrong: it's not a response to a resource. It contributes to a specific section of a response such as Header or Footer Agreed. I just haven't thought of a great name for it. IAmGoingToRenderYourStuffSomewhereResponse seemed a little unwieldy, and it was the best I had at the time. :) Perhaps IResourceContributions (to replace IHeaderResponse) and IResourceContributor (to replace IHeaderContributor) and contributeResources (to replace renderHead of IHeaderContributor)? -- Jeremy Thomerson http://wickettraining.com Need a CMS for Wicket? Use Brix! http://brixcms.org
Re: svn commit: r1050581 - in /wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation: AbstractDependencyRespectingResourceAggregatingHeaderResponse.java AbstractResourceAggregatingH
Any objections to me making this same change in 1.4.x? It would be an API
break, but on code that only appeared in the last release (1.4.14), and I
highly doubt anyone is using it yet.
I could, of course, add a backwards-compatible method, but it seems like
that's overkill for this brand new thing.
On Fri, Dec 17, 2010 at 9:32 PM, jrthomer...@apache.org wrote:
Author: jrthomerson
Date: Sat Dec 18 03:32:37 2010
New Revision: 1050581
URL: http://svn.apache.org/viewvc?rev=1050581view=rev
Log:
slight improvement to api of AbstractResourceAggregatingHeaderResponse.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java?rev=1050581r1=1050580r2=1050581view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java
Sat Dec 18 03:32:37 2010
@@ -66,7 +66,7 @@ public abstract class AbstractDependency
if (ref instanceof
AbstractResourceDependentResourceReference)
{
AbstractResourceDependentResourceReference
parent = (AbstractResourceDependentResourceReference)ref;
- R childColl =
newResourceReferenceCollection();
+ R childColl =
newResourceReferenceCollection(key);
for
(AbstractResourceDependentResourceReference child :
parent.getDependentResourceReferences())
{
childColl.add(toData(child));
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java?rev=1050581r1=1050580r2=1050581view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java
Sat Dec 18 03:32:37 2010
@@ -46,10 +46,10 @@ import org.apache.wicket.resource.Resour
* @author Jeremy Thomerson
* @param R
*the type of ResourceReferenceCollection returned by
- *{...@link #newResourceReferenceCollection()} and passed to all
the methods that take a
- *ResourceReferenceCollection. You will typically just use
ResourceReferenceCollection
- *for this param, unless you are returning a specific type of
- *ResourceReferenceCollection from your subclass.
+ *{...@link #newResourceReferenceCollection(Object)} and passed
to all the methods that
+ *take a ResourceReferenceCollection. You will typically just
use
+ *ResourceReferenceCollection for this param, unless you are
returning a specific type
+ *of ResourceReferenceCollection from your subclass.
* @param K
*the class of the key that you will create from
*{...@link #newGroupingKey(ResourceReferenceAndStringData)}
@@ -107,7 +107,7 @@ public abstract class AbstractResourceAg
R coll = map.get(key);
if (coll == null)
{
- map.put(key, coll =
newResourceReferenceCollection());
+ map.put(key, coll =
newResourceReferenceCollection(key));
}
coll.add(ref);
}
@@ -135,10 +135,13 @@ public abstract class AbstractResourceAg
* parameter used when creating your subclass defining the type of
ResourceReferenceCollection
* this returns and is passed into all methods that take a
ResourceReferenceCollection
*
+* @param key
+*the grouping key that will be used for this
collection. all references added to it
+*will have the same key
* @return a newly
Re: Moving wicket stuff to github
As long as we're top-posting with radical ideas, I'll do the same: We could adopt a linux-like model - We host one repo that has all the projects in it. - You want to create a wicketstuff project, you fork it and create your own directory in the source tree (either under ws-core or not - your choice). - We pull from your repo automatically for that directory only. Advantages: - we don't have to add collaborators or manage pull requests for individual subprojects - a subproject can add people as they desire - it can be automated It's similar to linux where they have maintainers for certain subtrees (i.e. USB modules), and linus' tree pulls from those trusted maintainers for those subtrees. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Thu, Dec 16, 2010 at 10:21 AM, Martin Grigorov mgrigo...@apache.orgwrote: the gain is in issue tracker and wiki each repo has its own issues with all-in-one the maintainer will have to look in all issues to check whether there is something for her project(s) On Thu, Dec 16, 2010 at 5:18 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: what would be the point of having them as submodules? it gains nothing but pain. since all projects need to be released at once the simplest way is to keep them in a single source tree. -igor On Thu, Dec 16, 2010 at 6:15 PM, Martin Grigorov mgrigo...@apache.org wrote: On Thu, Dec 16, 2010 at 5:04 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: I've claimed an organization for Wicket Stuff: https://github.com/wicketstuff and we can create multiple repos under that, and create and assign different teams to the repositories. How we organize things is just a matter of this debate ;) I have put a redirect from apache extras - wicket stuff - github, so we don't get fragmented. I'm going to look into doing something similar to the sf.net project (but after we have moved everything over) Next we need to discuss how to migrate everything over. Are we going to move whole wicketstuff over to one repo, or a git repo per project (where wicketstuff core counts as one project)? I would be even more radical - a repository for each project. wicketstuff-core will be a separate repository which will use git modules [1] to checkout the other repos and run mvn goals on them :-) But as Igor said all in one will be the simplest. 1. http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html Martijn
