Re: Display component feedback message once: "safety net" renders them always before

[Jeremy Thomerson]

On Tue, Jan 4, 2011 at 10:13 AM, 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).
>

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

[Jeremy Thomerson]

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 wrote:

> 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
>  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: onError missing from SubmitLink

[Jeremy Thomerson]

On Fri, Jan 14, 2011 at 2:22 PM, Martin Grigorov wrote:

> 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

[Jeremy Thomerson]

On Sat, Jan 15, 2011 at 4:17 AM, Leszek Gawron  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: svn commit: r1060043 - in /wicket/common/site/trunk: _site/start/quickstart.html start/quickstart.md

[Jeremy Thomerson]

This fixed the 1.5-SNAPSHOT quickstart problem- thanks!

On Mon, Jan 17, 2011 at 12:54 PM,  wrote:

> Author: mgrigorov
> Date: Mon Jan 17 18:54:55 2011
> New Revision: 1060043
>
> URL: http://svn.apache.org/viewvc?rev=1060043&view=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=1060043&r1=1060042&r2=1060043&view=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=1060043&r1=1060042&r2=1060043&view=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

[Jeremy Thomerson]

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
>  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: [vote] retry: release wicket 1.5-rc1

[Jeremy Thomerson]

On Thu, Jan 20, 2011 at 11:45 AM, Igor Vaynberg wrote:

> erm. we should be creating jira issues for these so we can seem them
> in the changelog. otherwise when we want to build rc2 it will look
> like there were no changes made.
>
> -igor
>

With all the top and bottom posting going on, it's hard to see which what
issues needed JIRAs.  Here's a summation of the issues in this thread (the
ones I saw, anyway) and their JIRAs.

NEED JIRA:
"fortify devutils" - http://svn.apache.org/viewvc?rev=1061176&view=rev
"Remove strange 'hidden' attribute of the password field." -
http://svn.apache.org/viewvc?rev=1061181&view=rev

ALREADY HAS JIRAL
Transitive dependencies - https://issues.apache.org/jira/browse/WICKET-3353

NEED OTHER ACTION:
README is out of date.


-- 
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*

Re: How to streamline ajax page region toggle

[Jeremy Thomerson]

On Thu, Jan 20, 2011 at 1:51 PM, Igor Vaynberg wrote:

> 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: [vote] retry: release wicket 1.5-rc1

[Jeremy Thomerson]

+1 to release

On Fri, Jan 21, 2011 at 4:10 PM, Igor Vaynberg wrote:

> +1 to release
>
> -igor
>
>
> On Tue, Jan 18, 2011 at 10:16 AM, Igor Vaynberg 
> 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=true&&pid=12310561&fixfor=12315483&sorter/field=issuekey&sorter/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: Do Lucene developers use FindBugs?

[Jeremy Thomerson]

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
wrote:

> So, what does this have to do with Lucene?
>
> 2011/1/24 César Couto :
> > 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

[Jeremy Thomerson]

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

[Jeremy Thomerson]

On Mon, Jan 24, 2011 at 11:32 AM, Igor Vaynberg wrote:

> 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?

[Jeremy Thomerson]

On Mon, Jan 24, 2011 at 11:51 AM, Eelco Hillenius  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

[Jeremy Thomerson]

On Mon, Jan 24, 2011 at 11:50 AM, Igor Vaynberg wrote:

>  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

[Jeremy Thomerson]

On Mon, Jan 24, 2011 at 12:36 PM, Martin Grigorov wrote:

> 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.

-- 
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

[Jeremy Thomerson]

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 wrote:
>
>> 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

[Jeremy Thomerson]

On Mon, Jan 24, 2011 at 12:47 PM, Igor Vaynberg wrote:

> 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

[Jeremy Thomerson]

On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg wrote:

> 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

[Jeremy Thomerson]

On Mon, Jan 24, 2011 at 4:40 PM, Jeremy Thomerson  wrote:

>
> On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg wrote:
>
>> 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: [discuss] How to resolve wicket aggregate classes / sources jar issues

[Jeremy Thomerson]

On Mon, Jan 24, 2011 at 4:41 PM, Jeremy Thomerson  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 
>> wrote:
>>
>>> 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

[Jeremy Thomerson]

On Tue, Jan 25, 2011 at 7:06 AM, James Carman wrote:

> 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*

Can't remember: way to add properties files for validators?

[Jeremy Thomerson]

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?

[Jeremy Thomerson]

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 wrote:

> 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
>  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?

[Jeremy Thomerson]

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?

[Jeremy Thomerson]

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
wrote:

> 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 
>
> > i wonder if hudson is publishing them somewhere...
> >
> > -igor
> >
> > On Thu, Feb 10, 2011 at 12:17 PM, Jeremy Thomerson
> >  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*
> > >
> >
>

WicketTester#assertInvisible

[Jeremy Thomerson]

I just ran across this nuance this week  If you have this:


  
  


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

[Jeremy Thomerson]

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

[Jeremy Thomerson]

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*

1.4.16 - adding methods to IBehavior

[Jeremy Thomerson]

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*

Re: 1.4.16 - adding methods to IBehavior

[Jeremy Thomerson]

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 wrote:

> 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
>  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*

Re: Reducing JIRA spam

[Jeremy Thomerson]

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 wrote:

> 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: [vote] release wicket 1.4.16

[Jeremy Thomerson]

+1

On Tue, Feb 22, 2011 at 10:30 AM, Igor Vaynberg wrote:

> +1
>
> -igor
>
> On Sun, Feb 20, 2011 at 8:33 PM, Igor Vaynberg 
> 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=12310561&version=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: [vote] release wicket 1.5-rc2

[Jeremy Thomerson]

+1 release

On Tue, Feb 22, 2011 at 10:31 AM, Igor Vaynberg wrote:

> +1
>
> -igor
>
> On Sun, Feb 20, 2011 at 8:34 PM, Igor Vaynberg 
> wrote:
> > This vote is to release wicket 1.5-rc2
> >
> > Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-rc2/
> > Artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-rc2/dist
> > Maven repo:
> https://repository.apache.org/content/repositories/orgapachewicket-031/
> > Changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561&version=12316059
> >
> > This vote ends Wednesday, February 23 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

[Jeremy Thomerson]

On Tue, Feb 22, 2011 at 4:10 PM, Bruno Borges wrote:

> 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: Usage of Session

[Jeremy Thomerson]

Maybe he means this line:

On Thu, Feb 24, 2011 at 2:42 AM, Martin Grigorov 
 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 
 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 wrote:

> On Thu, Feb 24, 2011 at 12:42 AM, Martin Grigorov 
> 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 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: Time for Wicket 1.5-RC3?

[Jeremy Thomerson]

On Mon, Mar 21, 2011 at 7:57 AM, Andrea Del Bene wrote:

> 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: Apache Wicket Cookbook Published!

[Jeremy Thomerson]

I had the privilege of previewing the book's content over the past few
months, and I can tell you that this book is going to be worth every penny
and then some!  I'd recommend it for every Wicket develop out there - even
if you think you've already "done it all".  I guarantee you'll pick up a
trick or two - I did!

-- 
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*


On Fri, Mar 25, 2011 at 1:44 PM, Igor Vaynberg wrote:

> For the past nine months I have been quietly working on a book about
> Wicket. Unlike other books on the market this one does not attempt to
> teach you Wicket from the ground up. Instead, it is for developers who
> already know the basics and want to learn how to implement some of the
> more advanced use cases. Essentially, it contains recipes that show
> the reader how to implement solutions to some of, what I think are,
> the most commonly asked questions and stumbling blocks. This morning I
> was informed that the book has been published! You can read more about
> it and pick up a copy on PACKT's Site[1]. I hope you enjoy it, more
> details below...
>
> [1] https://www.packtpub.com/apache-wicket-cookbook/book
>
> ## Description ##
>
> Apache Wicket is one of the most famous Java web application
> frameworks. Wicket simplifies web development and makes it fun. Are
> you bored of going through countless pages of theory to find out how
> to get your web development done? With this book in hand, you don't
> need to go through hundreds of pages to figure out how you will
> actually build a web application. You will get practical solutions to
> your common everyday development tasks to pace up your development
> activities.
>
> Apache Wicket Cookbook provides you with information that gets your
> problems solved quickly without beating around the bush. This book is
> perfect for you if you are ready to take the next step from tutorials
> and step into the practical world. It will take you beyond the basics
> of using Apache Wicket and show you how to leverage Wicket's advanced
> features to create simpler and more maintainable solutions to what at
> first may seem complex problems.
>
> You will learn how to integrate with client-side technologies such as
> JavaScript libraries or Flash components, which will help you to build
> your application faster. You will discover how to use Wicket paradigms
> to factor out commonly used code into custom Components, which will
> reduce the maintenance cost of your application, and how to leverage
> the existing Wicket Components to make your own code simpler.
>
> A straightforward Cookbook with highly focused practical recipes to
> make your web application development easier with the Wicket web
> framework
>
> ## What you will learn from this book ##
>
> * Leverage Wicket to implement a wide variety of both simple and
> advanced use cases in a narrative that gets straight to the point
> * Make forms work in the crazy world of the Web by learning the ways
> of Wicket's form processing
> * Simplify localizing your Wicket applications
> * Take the boring out of your forms by discovering how to improve the
> user experience while simplifying your code at the same time
> * Leverage the built-in Table component to make displaying tabular data a
> snap
> * Think Wicket's Borders are not very useful? Learn to use them in
> unexpected places to simplify things
> * See how to integrate with Flash components and create interactive
> charts at the same time
> * Web 1.0 too boring? Learn how to tame Wicket's AJAX support and
> bring your application into Web 2.0
> * Simplify your security code by learning various security techniques
> * An application cannot be built with Wicket alone; see how to make it
> play nice with other frameworks
>
> ## Approach ##
>
> This is a hands-on practical guide to a large variety of topics and
> use cases. This book tries to use real-world examples when possible,
> but is not afraid to come up with a contrived pretext if it makes
> explaining the problem simpler. Unlike a lot of other books, this one
> does not try to maintain a continuous theme from chapter to chapter,
> such as demonstrating solutions on the same fictional application;
> doing so would be almost impossible given the wide variety of recipes
> presented here. Instead, this book concentrates on focused problems
> users are likely to encounter and shows clear solutions in a
> step-by-step manner. This book tries to teach by example and is not
> afraid to show a lot of code because, after all, it is for coders.
>
> ## Who this book is written for ##
>
> This book is for current users of the Apache Wicket framework

Re: ResourceNameIterator for Mobile devices

[Jeremy Thomerson]

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 wrote:

> 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. _

Re: [Wicketstuff 1.5] Code formatting

[Jeremy Thomerson]

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 wrote:

> 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  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: Externalized Page Flow in Wicket

[Jeremy Thomerson]

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 wrote:

> 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
>  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
>

[vote] Release Wicket 1.4.18

[Jeremy Thomerson]

This vote is to release wicket 1.4.18. This is a bugfix release on the 1.4.x
(stable) branch.  See the changelog (http://s.apache.org/td) for more
details.

Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.18/
Maven Repository:
https://repository.apache.org/content/repositories/orgapachewicket-001
Non-Maven Build Artifacts:
http://people.apache.org/~jrthomerson/wicket-1.4.18/

This vote ends Monday, August 8th at 5:00am (GMT)

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*

Wicket Deployed on Nexus - THANKS!

[Jeremy Thomerson]

Thanks to all who were involved in getting Wicket deployed into Nexus and
updating the release documentation.  I hadn't done a release since the
switch.  Tonight I built the 1.4.18 release and deployed the staging repo
with Nexus.  It was great!!!  Thanks again for all your hard work on that!
 The guys doing this build stuff often get overlooked, but you deserve a
virtual-attaboy!

Best regards,

-- 
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

[Jeremy Thomerson]

+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"  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: Proposal: Moving wicketstuff.org Jenkins instance to a linux server (I volunteer to manage it)

[Jeremy Thomerson]

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] release wicket 1.5.2 take 3

[Jeremy Thomerson]

+1

On Fri, Oct 21, 2011 at 11:03 AM, Igor Vaynberg wrote:

> +1
>
> -igor
>
> On Thu, Oct 20, 2011 at 9:34 AM, Igor Vaynberg 
> 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=12310561&version=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: [vote] release wicket 1.5.3

[Jeremy Thomerson]

+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  wrote:

> +1
>
> Pedro Henrique Oliveira dos Santos
>
>
>
> 2011/11/11 Andrea Del Bene :
> > +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: integrating CDI into Wicket

[Jeremy Thomerson]

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"  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
>

Wicket will be migrating to Git

[Jeremy Thomerson]

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: Experimental work on ResourceReference management

[Jeremy Thomerson]

On Fri, Dec 2, 2011 at 3:33 AM, Emond Papegaaij
wrote:

> Note to Jeremy: I deleted some of the code you contributed to Wicket 1.5
> because there was a large overlap in functionality, and it proved
> difficult to
> keep the old code working as is. It would be great if you could shed some
> light on what the exact problem was, you were trying to solve with that
> code,
> so I can make sure that it can also be solved with this new approach.
>

Emond,

  It sounds like you have the use-cases pretty well covered.  Basically,
the goal of that work was to be able to define a hierarchy of resources
that depended on each other.  To be able to get that into 1.4 there were
some design compromises.  But, it enabled us to be able to include a single
resource and make sure that any other resources that were required by it
were included before it.  (For example, including a custom jQuery module
could force jQuery to be loaded before the module).

  Thanks for your efforts!  It sounds like you are making good progress for
a nice improvement to resources for Wicket 6!

-- 
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*

Request for help: simple GitHub test

[Jeremy Thomerson]

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 source code moved to Git

[Jeremy Thomerson]

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

[Jeremy Thomerson]

On Tue, Dec 20, 2011 at 11:20 PM, Clint Checketts wrote:

> 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

[Jeremy Thomerson]

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,  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 
> Authored: Tue Dec 20 20:10:17 2011 -0800
> Committer: Igor Vaynberg 
> 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*

Re: Wicket source code moved to Git

[Jeremy Thomerson]

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 wrote:
>
>> 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

[Jeremy Thomerson]

On Wed, Dec 21, 2011 at 1:40 PM, Johan Compagner wrote:

> 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*

Re: Roadmap for Wicket 6.0

[Jeremy Thomerson]

On Thu, Dec 22, 2011 at 2:29 AM, Sven Meier  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: Please welcome Emond Papegaaij as a committer for Wicket

[Jeremy Thomerson]

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: [vote] release wicket 1.5.4

[Jeremy Thomerson]

On Tue, Jan 10, 2012 at 4:10 PM, Martin Dilger  wrote:

> +1
> Am 10.01.2012 20:04 schrieb "Igor Vaynberg" :
>
> > 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: [vote] release Wicket 1.5.4.1

[Jeremy Thomerson]

+1

On Mon, Jan 16, 2012 at 2:39 PM, Peter Ertl  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 take 3

[Jeremy Thomerson]

+1

On Thu, Jan 19, 2012 at 11:47 AM, Igor Vaynberg wrote:

> +1
>
> -igor
>
> On Tue, Jan 17, 2012 at 8:34 PM, Igor Vaynberg 
> wrote:
> > This vote is to release wicket 1.5.4 take 3
> >
> > 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-084/
> >
> > 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 20th at 8:30pm (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: about webshere and relative url redirects: https://issues.apache.org/jira/browse/WICKET-3258

[Jeremy Thomerson]

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 wrote:

> 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: source/commits in jira

[Jeremy Thomerson]

Feel free to email infrastruct...@apache.org to bring the subject up there.

-- 
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*


On Fri, Feb 10, 2012 at 9:59 AM, Bertrand Guay-Paquet <
ber...@step.polymtl.ca> wrote:

> Hi,
>
> I asked the same question on dec 22 and Igor replied :
>
> infra is working on this afaik.
>
> -igor
>
>
> So I guess they haven't finished yet!
>
> Bertrand
>
>
> On 10/02/2012 9:34 AM, Johan Compagner wrote:
>
>> Hi,
>>
>> What "broke" now that we are over to git is the nice link between jira
>> issues and the source code
>> so this tab:
>>
>> https://issues.apache.org/**jira/browse/WICKET-1654?page=**com.atlassian.
>> **jirafisheyeplugin:fisheye-**issuepanel#issue-tabs<https://issues.apache.org/jira/browse/WICKET-1654?page=com.atlassian.jirafisheyeplugin:fisheye-issuepanel#issue-tabs>
>>
>> (or that subversion tab which ofcourse will not work anymore)
>>
>> is there a solution for that for GIT?
>> So that we can at least backtrack easy what is changed for a specific
>> issue?
>>
>>

Re: [vote] release wicket 1.4.20

[Jeremy Thomerson]

+1

On Sat, Mar 10, 2012 at 6:22 AM, Martin Grigorov
wrote:

> +1
> --
> Sent from my mobile phone. Please excuse my brevity.
>
> Andreas Pieber  wrote:
>
> Tested with pax-wicket and various related projects. Checked keys of
> artifacts and build source (with tests) successfully. Notice & LICENSE
> files look fine too.
>
> +1 (non-binding)
>
> Kind regards,
> Andreas
>
> On Thu, Mar 8, 2012 at 17:29, Igor Vaynberg 
> wrote:
> > +1
> >
> > -igor
> >
> > On Wed, Mar 7, 2012 at 8:46 AM, Igor Vaynberg 
> wrote:
> >> This vote is to release wicket 1.4.20
> >>
> >> Branch
> >>
> http://git-wip-us.apache.org/repos/asf/wicket/?p=wicket.git;a=shortlog;h=refs/heads/build/wicket-1.4.20
> >>
> >> Artifacts
> >> http://people.apache.org/~ivaynberg/wicket-1.4.20/dist/
> >>
> >> Maven repo
> >> https://repository.apache.org/content/repositories/orgapachewicket-065/
> >>
> >> Changelog
> >>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=fixVersion+%3D+%221.4.20%22+AND+project+%3D+WICKET
> >>
> >> This vote ends Saturday, March 10th at 9: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*

GitHub Pull Requests

[Jeremy Thomerson]

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: Site updates

[Jeremy Thomerson]

On Wed, Apr 4, 2012 at 7:58 PM, Jesse Long  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*

Multiple Git Workspaces From Single Repo

[Jeremy Thomerson]

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*

AllExceptFeedbackMessageFilter

[Jeremy Thomerson]

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*

Wicket 1.5 - duplicate JS detection broken?

[Jeremy Thomerson]

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*

Re: Releasing in a semver world (>= 6.x)

[Jeremy Thomerson]

On Tue, Sep 11, 2012 at 8:18 AM, Andrea Del Bene wrote:

> +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)

[Jeremy Thomerson]

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
>  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)

[Jeremy Thomerson]

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)

[Jeremy Thomerson]

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
>  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*

Re: [mostly devs] flyouts are dead

[Jeremy Thomerson]

On Thu, Sep 20, 2012 at 11:59 AM, Igor Vaynberg wrote:

> 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: Component setDefaultModel

[Jeremy Thomerson]

On Thu, Sep 27, 2012 at 1:59 PM, Igor Vaynberg wrote:

> 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

[Jeremy Thomerson]

On Thu, Sep 27, 2012 at 3:33 PM, tetsuo  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: A newer, flatter design for wicket site

[Jeremy Thomerson]

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: Upgrade jQuery to 1.10.0 in Wicket 6.x ?

[Jeremy Thomerson]

On Wed, May 29, 2013 at 4:40 PM, Martin Grigorov wrote:

> 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: Website: Fisheye link outdated

[Jeremy Thomerson]

I'll pass this to infra to see.  I'm not sure either.


On Mon, Jun 10, 2013 at 8:19 AM, Martin Grigorov wrote:

> I have no idea who has admin account for this service.
>
>
> On Mon, Jun 10, 2013 at 3:17 PM, Guillaume Smet  >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

[Jeremy Thomerson]

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 wrote:
>
>> I have no idea who has admin account for this service.
>>
>>
>> On Mon, Jun 10, 2013 at 3:17 PM, Guillaume Smet > >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: Authorization for IResource

[Jeremy Thomerson]

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 wrote:

> 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

[Jeremy Thomerson]

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 wrote:

> 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  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  >
> > > 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: [VOTE] Release Apache Wicket 6.9.0

[Jeremy Thomerson]

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 
> 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: Michael Mosmann is a committer and PMC member!

[Jeremy Thomerson]

Welcome Michael!


On Mon, Jul 1, 2013 at 11:47 AM, Igor Vaynberg wrote:

> welcome!
>
> -igor
>
> On Mon, Jul 1, 2013 at 2:51 AM, Martijn Dashorst
>  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: git commit: WICKET-5071 use url as clientUrl

[Jeremy Thomerson]

On Fri, Jul 12, 2013 at 7:34 AM, Sven Meier  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#457396


Besides, history rewriting is disallowed at ASF (for good reason).

Re: buildbot failure in ASF Buildbot on wicket-branch-6.x

[Jeremy Thomerson]

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 wrote:

> 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,  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 
> >
> > BUILD FAILED: failed compile
> >
> > sincerely,
> >  -The Buildbot
> >
> >
> >
> >
>



-- 
Jeremy Thomerson
http://wickettraining.com

Re: [VOTE] Accept the Wicket Free Guide as a part of Apache Wicket

[Jeremy Thomerson]

[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: Add .map files to default allowed files.

[Jeremy Thomerson]

On Sat, Sep 7, 2013 at 7:12 AM, Martin Grigorov wrote:

> 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: Wicket-5353: Wrap feedback messages in a model instead of using Serializable objects

[Jeremy Thomerson]

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.  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: [PROPOSE] Remove lists from nabble

[Jeremy Thomerson]

Do we have any control over Nabble configuration? Can we just stop them
from displaying any messages that were not accepted by the ML? Deleting a
bunch of moderation requests every now and then doesn't bother me - it
seems the folks using Nabble are the ones most affected since they see
those posts as if they were real posts.


On Fri, Jan 3, 2014 at 4:06 AM, Martijn Dashorst  wrote:

> With the amount of spam arriving at our lists through nabble, I am
> inclined to remove our affiliation with nabble altogether. While this
> sucks for some users, I (and I guess most of us) have no inclination
> to start policing a 3rd party that doesn't bother to implement a
> simple, decent and effective anti-spam solution.
>
> Cleaning up nabble would take serious work and time, better spent at
> doing work for the codebase.
>
> WDYT?
>
> Martijn
>



-- 
Jeremy Thomerson
http://wickettraining.com

Re: Apache + GitHub step 1

[Jeremy Thomerson]

Yes!


On Wed, Feb 12, 2014 at 2:18 AM, Martin Grigorov wrote:

> 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: ApacheCon EU 2014: (at least) 3 wicket presentations

[Jeremy Thomerson]

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: New committer: Jesse Long

[Jeremy Thomerson]

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

Wicket Stuff Commit Access

[Jeremy Thomerson]

I would like to add a new project to wicket-stuff.  It will be a calendar
component that displays events similar to Google calendar, etc.  I already
have a working prototype, but am not sure how to get a new sub-project
created and get started.

Thank you,
Jeremy Thomerson
[EMAIL PROTECTED]

Re: Wicket Stuff Commit Access

[Jeremy Thomerson]

jthomerson

On Jan 15, 2008 2:07 PM, Eelco Hillenius <[EMAIL PROTECTED]> wrote:

> Give us your sourceforge id and we'll give you commit access.
>
> Eelco
>
> On Jan 15, 2008 11:54 AM, Jeremy Thomerson
> <[EMAIL PROTECTED]> wrote:
> > I would like to add a new project to wicket-stuff.  It will be a
> calendar
> > component that displays events similar to Google calendar, etc.  I
> already
> > have a working prototype, but am not sure how to get a new sub-project
> > created and get started.
> >
> > Thank you,
> > Jeremy Thomerson
> > [EMAIL PROTECTED]
> >
>

Re: Wicket Stuff Commit Access

[Jeremy Thomerson]

Thanks!  Is there a "getting started" page somewhere that describes how to
set up a new wicket-stuff project?  Best practices, etc?  I couldn't find
much on the wiki except to email the dev list for commit access.

Thanks,
Jeremy

On Jan 15, 2008 3:16 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:

> added
>
> -igor
>
>
> On Jan 15, 2008 1:07 PM, Jeremy Thomerson
> <[EMAIL PROTECTED]> wrote:
> > jthomerson
> >
> >
> > On Jan 15, 2008 2:07 PM, Eelco Hillenius <[EMAIL PROTECTED]>
> wrote:
> >
> > > Give us your sourceforge id and we'll give you commit access.
> > >
> > > Eelco
> > >
> > > On Jan 15, 2008 11:54 AM, Jeremy Thomerson
> > > <[EMAIL PROTECTED]> wrote:
> > > > I would like to add a new project to wicket-stuff.  It will be a
> > > calendar
> > > > component that displays events similar to Google calendar, etc.  I
> > > already
> > > > have a working prototype, but am not sure how to get a new
> sub-project
> > > > created and get started.
> > > >
> > > > Thank you,
> > > > Jeremy Thomerson
> > > > [EMAIL PROTECTED]
> > > >
> > >
> >
>

RE: Planning Wicket Next Generation

[Jeremy Thomerson]

I definitely don't have any votes in this, but I have several production apps 
running with Wicket, and use 1.5 / generics in all of them.  Has there been any 
discussion of a faster release that ONLY includes generics?  Last I remember, 
someone had the generics patch(es) basically done, and just needed to apply 
them.

I would really like to see generics soon, but if they get put in with all the 
other features for 1.4, it would be 6-9 months (at least) before I could use 
them.

Jeremy Thomerson
-- sent from a wireless device

-Original Message-
From: "Johan Compagner" <[EMAIL PROTECTED]>
To: dev@wicket.apache.org
Sent: 3/14/08 4:23 PM
Subject: Re: Planning Wicket Next Generation

Its not that revolutionairy.
For example if 1.4 was just 1.3+generics then if your project like
vocus thats already on 1.5 it would be a drop in replacement. So api
and 'feature' wise not much has happend then, only easy of development
(for most not all are fans ;))

On 3/14/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> On 3/14/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > is the next release an evolution or revolution? :) i think first we
> >  need to make a list of all major things we want to go into it, and
> >  then decide.
>
> I think it counts as revolutionary: abandoning Java 1.4 is
> revolutionary I think.
>
> >  >  2 - are we going to timebox the milestones, or plan on features added?
> >
> > personally i think we should come up with a list of all the features
> >  we want, throw them into a backlog, and timebox it.
>
> See the wishlist: http://cwiki.apache.org/WICKET/wicket-14-wish-list.html
>
> >  >  3 - how many milestones do we plan?
> > id like 6. 1-4 dev, 5-6 stabalizaton. we were never able to get away
> >  with just one beta release before, most bugs are found after we put
> >  out the first beta...so i dont expect a lot of bugs to be found until
> >  the last dev milestone goes out.
>
> Fine with me.
>
> >  >  4 - which features go into each milestone?
> > what are the features? :)
>
> :D
>
> http://cwiki.apache.org/WICKET/wicket-14-wish-list.html
>
> Martijn
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.1 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
>

RE: Planning Wicket Next Generation

[Jeremy Thomerson]

Yes, I would love to see 1.4 be only generics if that meant we could have it 
soon (4-6 weeks???).  Then the other stuff could be 1.5 (or 2.0 or NG - 
whatever).

It seems like I'm not the only one suffering while waiting.

Jeremy Thomerson
-- sent from a wireless device

-Original Message-
From: "James Carman" <[EMAIL PROTECTED]>
To: dev@wicket.apache.org
Sent: 3/14/08 5:03 PM
Subject: Re: Planning Wicket Next Generation

On 3/14/08, Jeremy Thomerson <[EMAIL PROTECTED]> wrote:
> I definitely don't have any votes in this, but I have several production apps 
> running with Wicket, and use 1.5 / generics in all of them.  Has there been 
> any discussion of a faster release that ONLY includes generics?  Last I 
> remember, someone had the generics patch(es) basically done, and just needed 
> to apply them.
>
>  I would really like to see generics soon, but if they get put in with all 
> the other features for 1.4, it would be 6-9 months (at least) before I could 
> use them.

So, you're saying we should do 1.4 is just generifying Wicket and then
push the other stuff for 2.0?  So, anything 1.4+ would be JDK5+?

Re: Planning Wicket Next Generation

[Jeremy Thomerson]

It may be unlikely, but I foresee a potential problem with this.  A lot of
us are talking about moving our production apps to this release that
includes generics.  That means our bread and butter is dependent on it.
What if we push out a 1.4-M1 that has generics (+ miscellaneous), then
everyone starts working on other things, and in the meantime we discover a
bug in M1 that effects us?  We can't necessarily just drop in 1.4-M2,
because there are likely to be API breaks.  Do we all have to manage adding
patches to the release (1.4-M1-plus-custom-patches)?

That's one of the reasons many companies won't allow a milestone / beta
release to be depended on in production.  Can we think of another solution?
Perhaps 1.4 goes out quick, and to ease the concern of supporting 1.3 / 1.4/
1.5 concurrently, 1.4 only has limited support - for urgent / critical
patches?  Or someone from among us that really want generics would be
willing to do the merges / etc associated with supporting it?

I'm just throwing ideas out there - feel free to shoot me down with a much
better idea.

Jeremy Thomerson

On Fri, Mar 14, 2008 at 6:47 PM, Martijn Dashorst <
[EMAIL PROTECTED]> wrote:

> This is the plan.
>
> x-m1 is 1.3 + generics (+ any bugs that could be solved in the mean time).
>
> x-m2 is what we are planning now.
>
> Martijn
>
> On 3/14/08, Stefan Lindner <[EMAIL PROTECTED]> wrote:
> > And if the wicket core developers do not want to have 1.3 + 1.4 + 2.0 in
> parallel: I believe that we old wicket 2.0 users could live with xM1 (=1.3+ 
> Generics)
> >
> >  That means:
> >  1. Not need to support more than 2 branches/Versions
> >  2. Very quick generics for wicket based upan a stable release
> >  3. We old Wicket 2 users now can mitgrate to xM1, having new features
> and Generics
> >  4. We old Wicket 2 users have to suffer a few API changes until
> releasing x but I think we can live with this.
> >
> >  Stefan
> >
> >  -Ursprüngliche Nachricht-
> >  Von: Martin Benda [mailto:[EMAIL PROTECTED]
> >  Gesendet: Freitag, 14. März 2008 22:49
> >
> > An: dev@wicket.apache.org
> >  Betreff: Re: Planning Wicket Next Generation
> >
> >  ...and the answer is: We would like to see java5-only major release
> *ASAP* If you are going to add many new features in the next major release,
> those poor "early 2.0 adopters" (like me and my co-workers) will have to
> wait another 6-12 months...
> >
> >  +1 for 1.4 = 1.3 + java5 :-)
> >
> >  Bendis
> >
> >  Dne Friday 14 of March 2008 22:32:35 Igor Vaynberg napsal(a):
> >  > the question, sounds like, is not whether or not java5 will make it
> >  > into the next major release - that has always been a given, the
> >  > question is whether or not the next "major" release should simply be
> >  > 1.3+java5 stuff ONLY which would allow it to be released very
> >  > quickly...
> >  >
> >  > -igor
> >  >
> >  >
> >  > On Fri, Mar 14, 2008 at 2:25 PM, Martin Benda
> >  >
> >  > <[EMAIL PROTECTED]> wrote:
> >  > > Dear Wicket devs,
> >  > >
> >  > >  we are in the same situation too :-) For more than a year we are
> >  > > stuck to the dead 2.0 branch and are still hopefully awaiting the
> >  > > new generified major release. Old 2.0 with a few patches works
> quite
> >  > > fine but we won't probably survive waiting another year for the 1.4/2.0
> release...
> >  > >
> >  > >  So I'm totally +1 for adding only generics and other Java 1.5
> >  > > features in the next major release...
> >  > >
> >  > >  Regards,
> >  > >  Bendis
> >  > >
> >  > >  Dne Friday 14 of March 2008 22:14:56 Stefan Lindner napsal(a):
> >  > > > Dear Philip,
> >  > > >
> >  > >  > we are in the same situation. Just starting a new project, we  >
> >  > > discussed to write a generic wrapper for all the wicket classes  >
> >  > > (Model, Component, etc.). We are waiting for a generic wicket
> >  > > wersion  > now for a year. Having a genierfied wicket version
> (let's
> >  > > call it  > 1.4M1 or 2.0M1) wohlg make us sooo happ.
> >  > >  >
> >  > >  > Migration to wicket 1.3 was impossible because of heavy generic
> >  > > usage  > all around our code. It's hard to imagine how to use
> >  > > wicket's model  > without generics.
> >  > >  >
> >  > >  > I totally agree with your opini

Re: [vote] Release 1.4 with only generics and stop support for 1.3

[Jeremy Thomerson]

+1, Wicket 1.4 is 1.3 + generics, drop support for 1.3

On Mon, Mar 17, 2008 at 3:13 AM, Martijn Dashorst <
[EMAIL PROTECTED]> wrote:

> This thread is for voting only. Use the [discuss] thread for voicing
> your opinion or asking questions. This makes counting the votes much
> easier.
>
> The discussion on our development list makes it clear that a lot of
> folks are anxious for generified models. Most users if not all wish us
> to release a quick release which is 1.3 + generics. The consequence is
> that the core team will stop to support 1.3, and that everybody that
> wishes updates will have to migrate to 1.4, and upgrade to Java 5.
>
> Everybody is invited to vote! Please use
>
> [ ] +1, Wicket 1.4 is 1.3 + generics, drop support for 1.3
> [ ] -1, I need a supported version running on Java 1.4
>
> Let your voices be heard!
>
> Martijn
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.2 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2
>

Re: Fisheye for Wicket and Wicket Stuff

[Jeremy Thomerson]

Are these linked to anywhere on the http://wicket.apache.org site?  I am
away from my computer right now, and wanted to look at some Wicket code that
I was thinking about earlier, so I pulled up the site to go to the fisheye
view of the source - to no avail - I couldn't find the links.

Jeremy


On 3/16/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
>
> Atlassian has been kind enough to provide our community with fisheye
> on our repositories.
>
> You can see them here:
>
> Apache Wicket:
>
> http://fisheye6.cenqua.com/browse/wicket
>
>
> Wicket Stuff:
>
> http://fisheye3.cenqua.com/browse/wicket-stuff
>
> Martijn
>