Eelco Hillenius wrote:
>
> It's been in there for a while though, and the impact on the Wicket
> core project should be nill. The only thing that we have to take into
> account with the Wicket core project is that we shouldn't break Ate's
> rules, but I think that could only happen when we would
> I think the issue is how much extra time is needed to wait until the
> merged result can be proven in the wild to be stable enough.
> It may not affect only those who write portlets, but also those who
> don't.
>
> Frankly, I seldom see such significant new features being introduced
> in a beta s
yes, please. It looks like you are right, but changing it causes a
junit test to fail.
Juergen
On 9/18/07, Craig Lenzen <[EMAIL PROTECTED]> wrote:
>
> Really, still no response? Should I just log a JIRA bug?
>
> -Craig
>
>
> Craig Lenzen wrote:
> >
> > Just noticed this was originally posting in
Matej Knopp-2 wrote:
>
> I think it would be shame not to have portlet support in trunk if we
> can (and if it won't cause too many issues).
>
I think the issue is how much extra time is needed to wait until the
merged result can be proven in the wild to be stable enough.
It may not affect on
Really, still no response? Should I just log a JIRA bug?
-Craig
Craig Lenzen wrote:
>
> Just noticed this was originally posting in the user forum, it is probably
> better suited for the developers.
>
> I'm looking at the following block of code in the MockWebApplication
> within the method
I've created https://issues.apache.org/jira/browse/WICKET-983 to help out
reviewing the portlet-support changes.
Although I initially planned to create separate "sub" patches for reviewing the
important wicket changes individually, this turned out to be a
rather impossible task. The complete si
>
> Gerolf, was this closed (with won't fix) because of discussion you had
> with Nick?
sorry, clicked submit too early and was distracted by other things.
gerolf
Eelco
>
> On 9/17/07, Gerolf Seitz (JIRA) <[EMAIL PROTECTED]> wrote:
> >
> > [
> https://issues.apache.org/jira/browse/WICKET
Martijn Dashorst wrote:
Congratulations!
Thanks :)
So what is the verdict? Should we move portlet support back into
trunk? Or is this something that should be done after 1.3 final has
been released?
I've send out a separate message to the users list ealier in which I made clear
I'd like it
Martijn Dashorst wrote:
On 9/17/07, Ate Douma <[EMAIL PROTECTED]> wrote:
So what shall we do?
Once I have the JIRA issue for merging portlet support back into trunk ready,
you can all review it and if I don't hear any objections soon, I'll ask for a
vote, alright?
Sounds like a plan. Though
On 9/17/07, Ate Douma <[EMAIL PROTECTED]> wrote:
> > So what shall we do?
> Once I have the JIRA issue for merging portlet support back into trunk ready,
> you can all review it and if I don't hear any objections soon, I'll ask for a
> vote, alright?
Sounds like a plan. Though I would like it to
Gerolf, was this closed (with won't fix) because of discussion you had
with Nick?
Eelco
On 9/17/07, Gerolf Seitz (JIRA) <[EMAIL PROTECTED]> wrote:
>
> [
> https://issues.apache.org/jira/browse/WICKET-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Gerolf Seitz
Yeah, we discussed on IRC. I wasn't able to find a clean way to configure
the width.
On 9/17/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> Gerolf, was this closed (with won't fix) because of discussion you had
> with Nick?
>
> Eelco
>
> On 9/17/07, Gerolf Seitz (JIRA) <[EMAIL PROTECTED]> wro
Although I have no binding say in this I really would like this to go
into 1.3 asap. I'm trying to convince college's to use wicket based
portlets over JSF for our new portal based website. And having this in a
'final' release would really help me a lot.
+1 for commit in trunk (non-binding)
T
Just noticed this was originally posting in the user forum, it is probably
better suited for the developers.
I'm looking at the following block of code in the MockWebApplication within
the method that is listed in the subject of this post;
else if (target instance
I think it would be shame not to have portlet support in trunk if we
can (and if it won't cause too many issues).
-Matej
On 9/17/07, Thijs <[EMAIL PROTECTED]> wrote:
> Although I have no binding say in this I really would like this to go
> into 1.3 asap. I'm trying to convince college's to use wi
Congratulations!
So what is the verdict? Should we move portlet support back into
trunk? Or is this something that should be done after 1.3 final has
been released?
Based on the number of bugs still open, I'm reluctant to add another
feature into core that may introduce bugs. But I don't want the
>
> at runtime you use a wrong version of slf4j if you get that error
the quickstart archetype still uses version 1.0.1 for slf4j-log4j whereas
1.4.2 should be used.
gerolf
On 9/17/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > On 9/17/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >
at runtime you use a wrong version of slf4j if you get that error
On 9/17/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> On 9/17/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > somebody changed it from debug to trace so why is that done?
>
> Yeah, and that can give annoying error messages dep
On 9/17/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> somebody changed it from debug to trace so why is that done?
Yeah, and that can give annoying error messages depending on your config:
Exception in thread "ModificationWatcher Task"
java.lang.NoSuchMethodError: org.slf4j.Logger.isTraceEnabl
somebody changed it from debug to trace so why is that done?
On 9/17/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> This code:
>
> if (log.isTraceEnabled())
> {
> log.trace("Run the job: " + code.toString());
> }
>
> in Task looks completely unnecessary
20 matches
Mail list logo
