[] Apache Wicket Omega
i see most are voting for wicket 2.0 are we sure about that?
i think it won't even be that big api break (i really think it will be much
less then 1.2 - 1.3)
and it will be still very close to what we call now 2.0.. so it could be
confusing in the short term.
so mostly it
OK, so I think it will be fine if we also switch
- wicketstuff/trunk to wicketstuff/branches/wicket-2-DISCONTINUED
- wicketstuff/branches/wicket1.x to wicketstuff/trunk
--
Vincent
Martijn Dashorst a écrit :
We have now switched trunk and wicket 1.x in subversion. We have been
getting
On 4/19/07, Vincent Demay [EMAIL PROTECTED] wrote:
OK, so I think it will be fine if we also switch
- wicketstuff/trunk to wicketstuff/branches/wicket-2-DISCONTINUED
- wicketstuff/branches/wicket1.x to wicketstuff/trunk
I think it is best to coordinate this with contributors to
wicketstuff.
Martijn Dashorst wrote:
I propose we do the switch for wicketstuff at (or around) 6pm CET (for
us euros: 18:00 central european time).
OK.
Bart.
On 4/19/07, Vincent Demay [EMAIL PROTECTED] wrote:
If anyone else is willing to do it, fine by me, as long as we coordinate.
As you want, you can do it, but if you are bored with svn mv, I can do it
I don't mind doing it.
I propose we do the switch for wicketstuff at (or around) 6pm CET
Martijn Dashorst a écrit :
On 4/19/07, Vincent Demay [EMAIL PROTECTED] wrote:
If anyone else is willing to do it, fine by me, as long as we
coordinate.
As you want, you can do it, but if you are bored with svn mv, I can
do it
I don't mind doing it.
Ok, do it ;)
I propose we do the
* Martijn Dashorst:
This is a vote to promote 1.x to trunk and demote trunk to branches
with an appropiate label, and do it soon (as in now)
[x] yes, switch them
[ ] no, don't switch them
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
* Martijn Dashorst:
Apache Wicket 1.3 will be followed by:
[x] Apache Wicket 1.4
[ ] Apache Wicket 1.5 (after the JDK)
[ ] Apache Wicket 5 (similar, but more accurate)
[ ] Apache Wicket 2.0 (i.e. becomes our old 2.0 minus the c'tor change)
[ ] Apache Wicket 2007
[ ] Apache Wicket r59332
Wednesday, April 18, 2007, 11:04:12 PM, Martijn wrote:
There is a vote already in place for switching the development
branches around. Now it is time to name the release after 1.3 (and not
1.3.1 :).
Apache Wicket 1.3 will be followed by:
[+1] Apache Wicket 2.0 (i.e. becomes our old 2.0
Thursday, April 19, 2007, 10:51:15 AM, Jean-Baptiste wrote:
Can you please wait at least 24 or 48 hours before taking action,
and wait for more developers to express their opinion?
For European people like me the vote started yesterday evening
when leaving the office, and the switch from
[x] Apache Wicket 1.4 (Non-binding vote)
Having declared 2.0 a dead-end, you shouldn't release anything with
the same version number within six months at least - there's too much
potential for confusion IMHO. Not to mention tutorials and code
snippets that are floating around labelled for
Hi list,
I have a problem with error logging strategies. In our application, we use a
log4j SMTP appender, that sends out alarming emails in case of error logs.
However, we cannot properly control our wicket application as far as logging
is concerned. The problem is that this causes us to
All,
Following the recent shuffle in the Apache Wicket repository, we will
also restructure the Wicket Stuff repo in the same manner.
new trunk will become wicket 1.x
existing trunk will move to branches/wicket-2-DISCONTINUED
I'll take care of the new project that was added to trunk, so it
On 4/19/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
Can you please wait at least 24 or 48 hours before taking action,
and wait for more developers to express their opinion?
For European people like me the vote started yesterday evening
when leaving the office, and the switch from 1.x
* Ivo van Dongen:
I have a problem with error logging strategies. In our
application, we use a log4j SMTP appender, that sends out
alarming emails in case of error logs. However, we cannot
properly control our wicket application as far as logging is
concerned. The
All,
Since we did the package rename, and now that biggest API breakers of
the backports are in, shall we now build a new release for 1.3? This
release would be made available to the larger community. The IPMC
would be much more willing to check it in this case.
Questions:
- should we create a
Hi there,
What is the procedure to update the examples on wicketstuff.org?
http://wicketstuff.org/wicket13/
Also, it would be great to have Javadocs deployed online at each
build.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
To my best knowledge these get autodeployed by bamboo.
Martijn
On 4/19/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
Hi there,
What is the procedure to update the examples on wicketstuff.org?
http://wicketstuff.org/wicket13/
Also, it would be great to have Javadocs deployed online at
We will switch the svn branches in wicket-stuff too.
This is also completed as of now. Wicket Stuff svn now mirrors Wicket
svn in structure.
* Trunk of wicket stuff has been moved to branches/wicket-2-DISCONTINUED
* Branch wicket-1.x has been moved to trunk
If you have code checked out for
Questions:
- should we create a release this weekend?
Yes, please.
- how do we label it? [alpha, beta, general availability, ...]
Beta.
You want schedule some time in to go through JIRA as well?
Eelco
On 4/19/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
You want schedule some time in to go through JIRA as well?
I'll just build the release. I can schedule the cut of the code base
to a specific time, though. Especially if 1.2.6 is going out too (and
I have some writing to do as well).
I'd say one should allow more control: why not call a
protected method that has a default implementation of
log.error(e.getMessage, e) ? This way, one can easily adjust the
logging level by overriding this method in a subclass.
Check out the latest code, a new
its not just an api break. it is also the fact that we changed the
underlying technology. ive seen a lot of projects jump a major version when
they switched to jdk 1.5 without adding too many features.
it will also make it easier for martijn and eelco to continue with their
book as they dont
but i wonder if the symlink points to 1.3-snap or 1.3.0-snap?
-igor
On 4/19/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
To my best knowledge these get autodeployed by bamboo.
Martijn
On 4/19/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
Hi there,
What is the procedure to update
hrm, we used to have a symlink in tomcat's webapps dir that pointed to where
maven installed the jars, so it would all work automagically. but now i see
there is a copywicket13.sh that copies manually and the symlink is gone. any
reason johan?
-igor
On 4/19/07, Igor Vaynberg [EMAIL PROTECTED]
On 4/19/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
Since we did the package rename, and now that biggest API breakers of
the backports are in, shall we now build a new release for 1.3? This
release would be made available to the larger community. The IPMC
would be much more willing to
Charlie Dobbie wrote:
[x] Apache Wicket 1.4 (Non-binding vote)
Having declared 2.0 a dead-end, you shouldn't release anything with
the same version number within six months at least - there's too much
potential for confusion IMHO. Not to mention tutorials and code
snippets that are floating
On 19.4.2007, at 1.04, Martijn Dashorst wrote:
Apache Wicket 1.3 will be followed by:
[x] Apache Wicket 2.0 (i.e. becomes our old 2.0 minus the c'tor
change)
[x] Apache Wicket 7.05 - I'm an Ubuntu user... :D
On 4/19/07, Janne Hietamäki [EMAIL PROTECTED] wrote:
On 19.4.2007, at 1.04, Martijn Dashorst wrote:
Apache Wicket 1.3 will be followed by:
[x] Apache Wicket 2.0 (i.e. becomes our old 2.0 minus the c'tor
change)
--
Bruno Borges
Summa
This is a vote to release Wicket 1.2.6 this weekend.
There are still some issues open, but I hope they can be solved either
for we release, or we should just postpone them to 1.2.7
Open issues:
WICKET-268 NPE in ListView.renderItem(ListItem)
WICKET-349 ListView can't undo changes to
[x] Release wicket 1.2.6 regardless if these four issues are resolved
-igor
On 4/19/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
This is a vote to release Wicket 1.2.6 this weekend.
There are still some issues open, but I hope they can be solved either
for we release, or we should just
[ x ] Release wicket 1.2.6 regardless if these four issues are resolved
[ ] Release wicket 1.2.6 but I'll make sure these get fixed
[ ] Don't release wicket 1.2.6 until these four issues are resolved
Eelco
Release it but i think igor can fix them all first tonight.
On 4/20/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
This is a vote to release Wicket 1.2.6 this weekend.
There are still some issues open, but I hope they can be solved either
for we release, or we should just postpone them to
Something like class below (although perhaps more efficient) could help us to
decorate and merge javascript in our AJAX code. Because code merges only
occur one layer at a time, it's as good as an AST for our simple purposes
(we don't need to globally refactor JavaScript, for example, only
yeah, it's a little tricky, but i think the inheritance hierarchy can
provide the levels you're looking for (sort of as it does now) with
overrides and calls to super. i'm not sure exactly what you are asking me
to do, but the code might look like this (if i understand you right):
class
im not getting the warm and fuzzy about this. i want to, but im not.
take our base query which has the similar success and failure points as my
example. in order to facilitate those you still need the generic
ajaxcalldecorator design because those placeholders are inherited across
all layers,
it could be that i don't understand what we're doing well enough.
i certainly don't understand your specific concern. the throttling
decorator i showed you is completely generic and can decorate any
javascript code.
igor.vaynberg wrote:
im not getting the warm and fuzzy about this. i
don't forget that a javascript decorator isa JavaScript, so you can nest
them arbitrarily:
public static class ThrottlingDecorator extends JavaScript {
}
JavaScript code = new WhateverDecorator(new ThrottlingDecorator(script));
i'm still not getting what you think is missing from
your buildurl example cannot benefit from JavaScript because it is not
constructing code. it is constructing something to be merged into code, and
the way you've coded it below is exactly right. you'd just merge that in
with getUrl() overrides and super exactly the way you'd think. but for
On 20.4.2007, at 1.52, Martijn Dashorst wrote:
[x] Release wicket 1.2.6 regardless if these four issues are resolved
[ ] Release wicket 1.2.6 but I'll make sure these get fixed
[ ] Don't release wicket 1.2.6 until these four issues are resolved
40 matches
Mail list logo
