You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Boris Goldowsky <bg...@cast.org> on 2010/03/16 19:00:02 UTC
Wicketstuff versioning
The wicketstuff-core is calling itself version 1.4.2 in the HEAD of SVN.
Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket?
Bng
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by nino martinez wael <ni...@gmail.com>.
Exactly (I wrote something similar, but it apparently was declared spam:().
We could of course improve our structure as always, lifting the level a bit.
As I see it wicketstuff are as ops4j, which brings advantages and
disadvantages as well.
-regards Nino
2010/3/18 Martin Grigorov <mc...@e-card.bg>
> Here is how I understand wicketstuff hosting:
>
> Someone makes something cool and decides to share it with the community.
> Then this person asks in the mailing lists for commit permissions. After
> that this person jumps into something else and don't have time to
> support the project. Later on I need this cool feature and the first
> place to look for it is wicketstuff.org (you know because of the
> advertising in the mailing lists). Then I add or improve something to
> this project and again share it with the community. After me someone
> else does the same and the project lives. Otherwise some volunteer (like
> Jeremy) decides that this project is not maintained and moves it to
> attic.
>
> About GoogleCode, github, bitbucket, ... yes, you can put your project
> there. But there are two problems:
> 1) it is less visible
> it is not next to the other wicketstuff projects where everyone checks
> first
> 2) when you don't have time to support it you need to give commit
> permissions to the people who have time or they will start clone it all
> over Internet. And this will just confuse further future
> users/maintainers
>
> On Wed, 2010-03-17 at 15:25 -0400, Boris Goldowsky wrote:
> > It sounds like whoever is responsible for wicketstuff needs to make a
> > clear choice here.
> >
> > Is Wicketstuff going to be maintained as a place where lots of useful
> > add-ons will live? If so, it needs someone to take a slightly more
> > active role as curator; make sure the releases are done in parallel with
> > wicket releases, make sure modules don't get dumped there without at
> > least some documentation; and weed out modules that are abandoned, where
> > no one volunteers to take on maintenance, or whose function has been
> > absorbed into wicket's core.
> >
> > Alternatively, make it clear that wicketstuff is NOT going to be
> > maintained, and people like me who would like to share modules will
> > share them in some other way - on Google code, a personal website, or
> > whatever.
> >
> > Either way is ok I think, it just would be useful for those of us who
> > are interested in contributing modules to know.
> >
> > Thanks
> > Bng
> >
> >
> > Jeremy Thomerson wrote:
> > > Really, it should match what's at trunk of Wicket, which should be
> > > 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT.
> > > But, nobody is really maintaining it any more, so it's a free-for-all.
> > > That's always been the problem with WicketStuff.
> > >
> > > --
> > > Jeremy Thomerson
> > > http://www.wickettraining.com
> > >
> > >
> > >
> > > On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky <bgoldowsky@cast.org
> >wrote:
> > >
> > >
> > >> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of
> SVN.
> > >> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket?
> > >>
> > >> Bng
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >>
> > >>
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: Wicketstuff versioning
Posted by Stefan Lindner <li...@visionet.de>.
Perhaps we should define an island of stability (like the name wickststuff-core implies). Maybe under another name (e.g. wicketstuff-stable).
This place should only hold projects that are maintained and that are buildable with actual wicket versions. The rest of wicketstuff should be left as ist is: free for everyone and sometimes out of date.
Even if a project is not supported anymore t might be helpful to get some inspiration for my own work.
And: YES, I would help to maintain such a stable core of wicketstuff.
Stefan
-----Ursprüngliche Nachricht-----
Von: Martin Grigorov [mailto:mcgregory@e-card.bg]
Gesendet: Donnerstag, 18. März 2010 09:09
An: users@wicket.apache.org
Betreff: Re: Wicketstuff versioning
Here is how I understand wicketstuff hosting:
Someone makes something cool and decides to share it with the community.
Then this person asks in the mailing lists for commit permissions. After
that this person jumps into something else and don't have time to
support the project. Later on I need this cool feature and the first
place to look for it is wicketstuff.org (you know because of the
advertising in the mailing lists). Then I add or improve something to
this project and again share it with the community. After me someone
else does the same and the project lives. Otherwise some volunteer (like
Jeremy) decides that this project is not maintained and moves it to
attic.
About GoogleCode, github, bitbucket, ... yes, you can put your project
there. But there are two problems:
1) it is less visible
it is not next to the other wicketstuff projects where everyone checks
first
2) when you don't have time to support it you need to give commit
permissions to the people who have time or they will start clone it all
over Internet. And this will just confuse further future
users/maintainers
On Wed, 2010-03-17 at 15:25 -0400, Boris Goldowsky wrote:
> It sounds like whoever is responsible for wicketstuff needs to make a
> clear choice here.
>
> Is Wicketstuff going to be maintained as a place where lots of useful
> add-ons will live? If so, it needs someone to take a slightly more
> active role as curator; make sure the releases are done in parallel with
> wicket releases, make sure modules don't get dumped there without at
> least some documentation; and weed out modules that are abandoned, where
> no one volunteers to take on maintenance, or whose function has been
> absorbed into wicket's core.
>
> Alternatively, make it clear that wicketstuff is NOT going to be
> maintained, and people like me who would like to share modules will
> share them in some other way - on Google code, a personal website, or
> whatever.
>
> Either way is ok I think, it just would be useful for those of us who
> are interested in contributing modules to know.
>
> Thanks
> Bng
>
>
> Jeremy Thomerson wrote:
> > Really, it should match what's at trunk of Wicket, which should be
> > 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT.
> > But, nobody is really maintaining it any more, so it's a free-for-all.
> > That's always been the problem with WicketStuff.
> >
> > --
> > Jeremy Thomerson
> > http://www.wickettraining.com
> >
> >
> >
> > On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky <bg...@cast.org>wrote:
> >
> >
> >> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of SVN.
> >> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket?
> >>
> >> Bng
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Martin Grigorov <mc...@e-card.bg>.
Here is how I understand wicketstuff hosting:
Someone makes something cool and decides to share it with the community.
Then this person asks in the mailing lists for commit permissions. After
that this person jumps into something else and don't have time to
support the project. Later on I need this cool feature and the first
place to look for it is wicketstuff.org (you know because of the
advertising in the mailing lists). Then I add or improve something to
this project and again share it with the community. After me someone
else does the same and the project lives. Otherwise some volunteer (like
Jeremy) decides that this project is not maintained and moves it to
attic.
About GoogleCode, github, bitbucket, ... yes, you can put your project
there. But there are two problems:
1) it is less visible
it is not next to the other wicketstuff projects where everyone checks
first
2) when you don't have time to support it you need to give commit
permissions to the people who have time or they will start clone it all
over Internet. And this will just confuse further future
users/maintainers
On Wed, 2010-03-17 at 15:25 -0400, Boris Goldowsky wrote:
> It sounds like whoever is responsible for wicketstuff needs to make a
> clear choice here.
>
> Is Wicketstuff going to be maintained as a place where lots of useful
> add-ons will live? If so, it needs someone to take a slightly more
> active role as curator; make sure the releases are done in parallel with
> wicket releases, make sure modules don't get dumped there without at
> least some documentation; and weed out modules that are abandoned, where
> no one volunteers to take on maintenance, or whose function has been
> absorbed into wicket's core.
>
> Alternatively, make it clear that wicketstuff is NOT going to be
> maintained, and people like me who would like to share modules will
> share them in some other way - on Google code, a personal website, or
> whatever.
>
> Either way is ok I think, it just would be useful for those of us who
> are interested in contributing modules to know.
>
> Thanks
> Bng
>
>
> Jeremy Thomerson wrote:
> > Really, it should match what's at trunk of Wicket, which should be
> > 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT.
> > But, nobody is really maintaining it any more, so it's a free-for-all.
> > That's always been the problem with WicketStuff.
> >
> > --
> > Jeremy Thomerson
> > http://www.wickettraining.com
> >
> >
> >
> > On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky <bg...@cast.org>wrote:
> >
> >
> >> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of SVN.
> >> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket?
> >>
> >> Bng
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Jeremy Thomerson <je...@wickettraining.com>.
See other reply to Boris. Anyone can pick it up and become the maintainer
of WS. But it's going to take a group of people who set some rules about it
and then follow them. The problem with that is that then people *will*
whine because they always wanted WicketStuff to be a no-rules repo. I would
like to see the wicketstuff-core things that I reorganized last year (and
the year before) to continue to make progress and be released consistently.
But I don't have the time, and when I asked for help, although there were
offers, no one ever stepped up to the plate. So, if the community doesn't
care that much, why should I? I'd rather put my time into things that I can
actually control and make a positive effect with.
--
Jeremy Thomerson
http://www.wickettraining.com
2010/3/17 Major Péter <ma...@sch.bme.hu>
> I always thought, that Jeremy was the maintainer of WicketStuff. Guess I
> was wrong. :)
> Sidenote:
> Also, I really wanted to write docs for the javaee-inject project, but I
> don't have confluence access, and the signup gives:
> org.springframework.transaction.UnexpectedRollbackException: Transaction
> rolled back because it has been marked as rollback-only
>
> I guess this isn't working since the overspammed confluence event. I
> already wrote two e-mails to the dev list, but still no answer, so I'm
> confused too about the wicketstuff's future...
>
> Regards,
> Peter
>
> 2010-03-17 20:25 keltezéssel, Boris Goldowsky írta:
> > It sounds like whoever is responsible for wicketstuff needs to make a
> > clear choice here.
> >
> > Is Wicketstuff going to be maintained as a place where lots of useful
> > add-ons will live? If so, it needs someone to take a slightly more
> > active role as curator; make sure the releases are done in parallel with
> > wicket releases, make sure modules don't get dumped there without at
> > least some documentation; and weed out modules that are abandoned, where
> > no one volunteers to take on maintenance, or whose function has been
> > absorbed into wicket's core.
> >
> > Alternatively, make it clear that wicketstuff is NOT going to be
> > maintained, and people like me who would like to share modules will
> > share them in some other way - on Google code, a personal website, or
> > whatever.
> >
> > Either way is ok I think, it just would be useful for those of us who
> > are interested in contributing modules to know.
> >
> > Thanks
> > Bng
> >
> >
> > Jeremy Thomerson wrote:
> >> Really, it should match what's at trunk of Wicket, which should be
> >> 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT.
> >> But, nobody is really maintaining it any more, so it's a free-for-all.
> >> That's always been the problem with WicketStuff.
> >>
> >> --
> >> Jeremy Thomerson
> >> http://www.wickettraining.com
> >>
> >>
> >>
> >> On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky
> >> <bg...@cast.org>wrote:
> >>
> >>
> >>> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of
> SVN.
> >>> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket?
> >>>
> >>> Bng
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicketstuff versioning
Posted by Major Péter <ma...@sch.bme.hu>.
I always thought, that Jeremy was the maintainer of WicketStuff. Guess I
was wrong. :)
Sidenote:
Also, I really wanted to write docs for the javaee-inject project, but I
don't have confluence access, and the signup gives:
org.springframework.transaction.UnexpectedRollbackException: Transaction
rolled back because it has been marked as rollback-only
I guess this isn't working since the overspammed confluence event. I
already wrote two e-mails to the dev list, but still no answer, so I'm
confused too about the wicketstuff's future...
Regards,
Peter
2010-03-17 20:25 keltezéssel, Boris Goldowsky írta:
> It sounds like whoever is responsible for wicketstuff needs to make a
> clear choice here.
>
> Is Wicketstuff going to be maintained as a place where lots of useful
> add-ons will live? If so, it needs someone to take a slightly more
> active role as curator; make sure the releases are done in parallel with
> wicket releases, make sure modules don't get dumped there without at
> least some documentation; and weed out modules that are abandoned, where
> no one volunteers to take on maintenance, or whose function has been
> absorbed into wicket's core.
>
> Alternatively, make it clear that wicketstuff is NOT going to be
> maintained, and people like me who would like to share modules will
> share them in some other way - on Google code, a personal website, or
> whatever.
>
> Either way is ok I think, it just would be useful for those of us who
> are interested in contributing modules to know.
>
> Thanks
> Bng
>
>
> Jeremy Thomerson wrote:
>> Really, it should match what's at trunk of Wicket, which should be
>> 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT.
>> But, nobody is really maintaining it any more, so it's a free-for-all.
>> That's always been the problem with WicketStuff.
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>> On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky
>> <bg...@cast.org>wrote:
>>
>>
>>> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of SVN.
>>> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket?
>>>
>>> Bng
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Jeremy Thomerson <je...@wickettraining.com>.
2010/3/19 Major Péter <ma...@sch.bme.hu>
> Hi,
>
> count me in. I would like to help maintain wicketstuff-core too. ;)
> When I came to build wicketstuff-core, sometimes I end up fixing
> dependency issues and other stuff in others projects, but I don't commit
> them, because I don't want to modify someone else's code without her/his
> knowledge, and finding out who is the current maintainer of the project
> is not that simple... Am I the only one with this? Or if I catch for
> example a maven config bug, should I just fix and commit them to make
> the repo right?
>
I have hit the same problem in the past. Before, I never did like changing
someone else's project without their permission. But, then I decided that
if I was trying to build a release, and it was just a Maven config or a
simple compile issue, I fixed it and committed it - without asking. And if
it wasn't simple to fix, I commented out that module (in the
wicketstuff-core pom) and then built without that piece.
--
Jeremy Thomerson
http://www.wickettraining.com
Re: Wicketstuff versioning
Posted by Major Péter <ma...@sch.bme.hu>.
Hi,
count me in. I would like to help maintain wicketstuff-core too. ;)
When I came to build wicketstuff-core, sometimes I end up fixing
dependency issues and other stuff in others projects, but I don't commit
them, because I don't want to modify someone else's code without her/his
knowledge, and finding out who is the current maintainer of the project
is not that simple... Am I the only one with this? Or if I catch for
example a maven config bug, should I just fix and commit them to make
the repo right?
Regards,
Peter
2010-03-19 15:04 keltezéssel, Boris Goldowsky írta:
> nino martinez wael wrote:
>> I'll be happy to join in Boris.
>>
> That would be awesome, thanks Nino.
>
> I'm thinking the first thing would be to bump the wicket dependency to
> v1.4.7 and do a maven release of the current state of wicketstuff-core
> as version 1.4.7. Make sense? Is that something you could do?
>
> Stefan Lindner wrote:
>> Perhaps we should define an island of stability (like the name
>> wickststuff-core implies).
> I agree with that & the rest of your message. Jeremy put together a
> nice framework under wicketstuff-core, and there are a decent set of
> modules in there. How about calling those the stable set. Anyone can
> put something into core - as long as it works and they're willing to
> make some effort to keep it working. If one of the core modules breaks
> with a future wicket version, and no one steps up to fix it, then it
> gets dropped out of wicketstuff-core.
>
>> And: YES, I would help to maintain such a stable core of wicketstuff.
> Great!! I think with 4 or 5 people it shouldn't be a terrible task.
> (of course I could be wrong...)
>
> Bng
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: How to construct/generate AjaxRequestTarget for a WebPage,
without explicitly being fired from
AjaxButton/AjaxLink/AjaxSelfUpdatingTimerBehavior
Posted by Martin Asenov <mA...@velti.com>.
Here's the issue:
Modal window is displayed. The user gets idle for a while. I've registered the modal by its session ID.
When the user clicks on some AjaxLink/AjaxButton and I want to see if session is invalid, so I've overridden sessionDestroyed() in the webapp, which calls a method that should close the modal, just like this:
modal.close((AjaxRequestTarget) RequestCycle.get().getRequestTarget());
but it doesn't work.
Best,
Martin
-----Original Message-----
From: Martijn Dashorst [mailto:martijn.dashorst@gmail.com]
Sent: Friday, March 19, 2010 5:42 PM
To: users@wicket.apache.org
Subject: Re: How to construct/generate AjaxRequestTarget for a WebPage, without explicitly being fired from AjaxButton/AjaxLink/AjaxSelfUpdatingTimerBehavior
So how does the server communicate the close call to the client?
Martijn
On Fri, Mar 19, 2010 at 4:29 PM, Martin Asenov <mA...@velti.com> wrote:
> No, it's something like:
>
> new Timer().schedule(new TimerTask() {
> public void run() {
> modal.close(the target);
> }
> }, 120000);
>
> Best,
> Martin
>
>
> -----Original Message-----
> From: Martin Makundi [mailto:martin.makundi@koodaripalvelut.com]
> Sent: Friday, March 19, 2010 5:23 PM
> To: users@wicket.apache.org
> Subject: Re: How to construct/generate AjaxRequestTarget for a WebPage, without explicitly being fired from AjaxButton/AjaxLink/AjaxSelfUpdatingTimerBehavior
>
> Yes .. don't do new AjaxTarget... use the one you are given, why not?
> It is an ajax event, no?
>
> **
> Martin
>
> 2010/3/19 Martin Asenov <mA...@velti.com>:
>> To me modalWindow.close(new AjaxRequestTarget(containerPage)) doesn't work...
>> And RequestCycle.get().getRequestTarget() returns null;
>>
>> Please help...
>>
>> Best,
>> Martin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to construct/generate AjaxRequestTarget for a WebPage,
without explicitly being fired from AjaxButton/AjaxLink/AjaxSelfUpdatingTimerBehavior
Posted by Martijn Dashorst <ma...@gmail.com>.
So how does the server communicate the close call to the client?
Martijn
On Fri, Mar 19, 2010 at 4:29 PM, Martin Asenov <mA...@velti.com> wrote:
> No, it's something like:
>
> new Timer().schedule(new TimerTask() {
> public void run() {
> modal.close(the target);
> }
> }, 120000);
>
> Best,
> Martin
>
>
> -----Original Message-----
> From: Martin Makundi [mailto:martin.makundi@koodaripalvelut.com]
> Sent: Friday, March 19, 2010 5:23 PM
> To: users@wicket.apache.org
> Subject: Re: How to construct/generate AjaxRequestTarget for a WebPage, without explicitly being fired from AjaxButton/AjaxLink/AjaxSelfUpdatingTimerBehavior
>
> Yes .. don't do new AjaxTarget... use the one you are given, why not?
> It is an ajax event, no?
>
> **
> Martin
>
> 2010/3/19 Martin Asenov <mA...@velti.com>:
>> To me modalWindow.close(new AjaxRequestTarget(containerPage)) doesn't work...
>> And RequestCycle.get().getRequestTarget() returns null;
>>
>> Please help...
>>
>> Best,
>> Martin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: How to construct/generate AjaxRequestTarget for a WebPage,
without explicitly being fired from
AjaxButton/AjaxLink/AjaxSelfUpdatingTimerBehavior
Posted by Martin Asenov <mA...@velti.com>.
No, it's something like:
new Timer().schedule(new TimerTask() {
public void run() {
modal.close(the target);
}
}, 120000);
Best,
Martin
-----Original Message-----
From: Martin Makundi [mailto:martin.makundi@koodaripalvelut.com]
Sent: Friday, March 19, 2010 5:23 PM
To: users@wicket.apache.org
Subject: Re: How to construct/generate AjaxRequestTarget for a WebPage, without explicitly being fired from AjaxButton/AjaxLink/AjaxSelfUpdatingTimerBehavior
Yes .. don't do new AjaxTarget... use the one you are given, why not?
It is an ajax event, no?
**
Martin
2010/3/19 Martin Asenov <mA...@velti.com>:
> To me modalWindow.close(new AjaxRequestTarget(containerPage)) doesn't work...
> And RequestCycle.get().getRequestTarget() returns null;
>
> Please help...
>
> Best,
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to construct/generate AjaxRequestTarget for a WebPage,
without explicitly being fired from AjaxButton/AjaxLink/AjaxSelfUpdatingTimerBehavior
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
Yes .. don't do new AjaxTarget... use the one you are given, why not?
It is an ajax event, no?
**
Martin
2010/3/19 Martin Asenov <mA...@velti.com>:
> To me modalWindow.close(new AjaxRequestTarget(containerPage)) doesn't work...
> And RequestCycle.get().getRequestTarget() returns null;
>
> Please help...
>
> Best,
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to return a result value for wicketAjaxGet
Posted by vineet semwal <vi...@gmail.com>.
forgot to add the concatenation result has to be passed as argument to
wicketajaxget as you already know..
On Fri, Mar 19, 2010 at 9:03 PM, vineet semwal
<vi...@gmail.com>wrote:
> Hi,
> take a look at
> http://cwiki.apache.org/WICKET/calling-wicket-from-javascript.html
>
> following is what you need to do ..
>
> you can concatenate the value you want to return as paramter in
> callbackurl,we will read this back as request
> parameter from java.
>
> it should look like callbackurl+"&"+component markupid+"="+args;
>
> then in your respond method you can easily read request parameter from url
> .
> String paramFoo = RequestCycle.get().getRequest().getParameter("component
> markupid");
>
>
>
> On Fri, Mar 19, 2010 at 7:51 PM, Stefan Lindner <li...@visionet.de>wrote:
>
>> If I place a call to wicketAjaxGet(...) into a eg.g onclick attribute
>> with the help of an AjaxBehavior, the method respond(final
>> AjaxRequestTarget target) is called on the Java side.
>>
>> Is it possible to build a call to wicketAjaxGet like
>>
>> var result = wicketAjaxGet(...);
>>
>> and provid the result value in the respond method on the Java side?
>>
>> Does anobody know the trick?
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> regards,
> Vineet Semwal
>
--
regards,
Vineet Semwal
Re: How to return a result value for wicketAjaxGet
Posted by Igor Vaynberg <ig...@gmail.com>.
you have to put your alert code into the success handler. this is all
happening asynchronously
-igor
On Fri, Mar 19, 2010 at 10:20 AM, Stefan Lindner <li...@visionet.de> wrote:
> Hi Igor,
>
> you mean
>
> onclick="
> myVar = 'some value';
> wicketAjaxGet(this.getCallbackUrl()+&variableName='myVar');
> /*start of java processing in the backend*/
> protected void respond(final AjaxRequestTarget target) {
> Component component = getComponent();
> Request request;
> if (component != null && (request = component.getRequest()) != null) {
> String variableName = request.getParameter("variableName");
> target.appendJavascript(variableName"='some OTHER value';");
> }
> //should now be 'some OTHER value' but is still 'some value'
> alert('myVar = ' + myvar);
> "
>
> This does not work. The javascript that was appended to the target gets evaluated AFTER the alert call.
> Or did I miss something?
>
> Stefan
>
> -----Ursprüngliche Nachricht-----
> Von: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
> Gesendet: Freitag, 19. März 2010 17:16
> An: users@wicket.apache.org
> Betreff: Re: How to return a result value for wicketAjaxGet
>
> append the name of the variable to the url, in target generate js that
> sets the variable to the value. after wicketajaxget processes the
> result the value should be set
>
> -igor
>
> On Fri, Mar 19, 2010 at 8:52 AM, Stefan Lindner <li...@visionet.de> wrote:
>> Hi Vineet,
>>
>> that's true. I already know this but this is not what I need. I need the opposite thing. What you explained is something like an input parameter to wicketAjaxGet. This input parameters can easily be fetches from the Request.
>>
>> But what I need is a return value for wicketAjaxGet. That is visible in the javascript code AFTER doing something in respond.
>>
>> This means
>>
>>
>> Have some javascript on the page like
>>
>> var result = wicketAjaxGet(...)&someParameter...;
>> // do the respond() mehtod processing on the javaside and return a value
>> alert('result of respond processing' = result);
>>
>> Stefan
>>
>> -----Ursprüngliche Nachricht-----
>> Von: vineet semwal [mailto:vineetsemwal1982@gmail.com]
>> Gesendet: Freitag, 19. März 2010 16:34
>> An: users@wicket.apache.org
>> Betreff: Re: How to return a result value for wicketAjaxGet
>>
>> Hi,
>> take a look at
>> http://cwiki.apache.org/WICKET/calling-wicket-from-javascript.html
>>
>> following is what you need to do ..
>>
>> you can concatenate the value you want to return as paramter in
>> callbackurl,we will read this back as request
>> parameter from java.
>>
>> it should look like callbackurl+"&"+component markupid+"="+args;
>>
>> then in your respond method you can easily read request parameter from url .
>> String paramFoo = RequestCycle.get().getRequest().getParameter("component
>> markupid");
>>
>>
>> On Fri, Mar 19, 2010 at 7:51 PM, Stefan Lindner <li...@visionet.de> wrote:
>>
>>> If I place a call to wicketAjaxGet(...) into a eg.g onclick attribute
>>> with the help of an AjaxBehavior, the method respond(final
>>> AjaxRequestTarget target) is called on the Java side.
>>>
>>> Is it possible to build a call to wicketAjaxGet like
>>>
>>> var result = wicketAjaxGet(...);
>>>
>>> and provid the result value in the respond method on the Java side?
>>>
>>> Does anobody know the trick?
>>>
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> --
>> regards,
>> Vineet Semwal
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
AW: How to return a result value for wicketAjaxGet
Posted by Stefan Lindner <li...@visionet.de>.
Hi Igor,
you mean
onclick="
myVar = 'some value';
wicketAjaxGet(this.getCallbackUrl()+&variableName='myVar');
/*start of java processing in the backend*/
protected void respond(final AjaxRequestTarget target) {
Component component = getComponent();
Request request;
if (component != null && (request = component.getRequest()) != null) {
String variableName = request.getParameter("variableName");
target.appendJavascript(variableName"='some OTHER value';");
}
//should now be 'some OTHER value' but is still 'some value'
alert('myVar = ' + myvar);
"
This does not work. The javascript that was appended to the target gets evaluated AFTER the alert call.
Or did I miss something?
Stefan
-----Ursprüngliche Nachricht-----
Von: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
Gesendet: Freitag, 19. März 2010 17:16
An: users@wicket.apache.org
Betreff: Re: How to return a result value for wicketAjaxGet
append the name of the variable to the url, in target generate js that
sets the variable to the value. after wicketajaxget processes the
result the value should be set
-igor
On Fri, Mar 19, 2010 at 8:52 AM, Stefan Lindner <li...@visionet.de> wrote:
> Hi Vineet,
>
> that's true. I already know this but this is not what I need. I need the opposite thing. What you explained is something like an input parameter to wicketAjaxGet. This input parameters can easily be fetches from the Request.
>
> But what I need is a return value for wicketAjaxGet. That is visible in the javascript code AFTER doing something in respond.
>
> This means
>
>
> Have some javascript on the page like
>
> var result = wicketAjaxGet(...)&someParameter...;
> // do the respond() mehtod processing on the javaside and return a value
> alert('result of respond processing' = result);
>
> Stefan
>
> -----Ursprüngliche Nachricht-----
> Von: vineet semwal [mailto:vineetsemwal1982@gmail.com]
> Gesendet: Freitag, 19. März 2010 16:34
> An: users@wicket.apache.org
> Betreff: Re: How to return a result value for wicketAjaxGet
>
> Hi,
> take a look at
> http://cwiki.apache.org/WICKET/calling-wicket-from-javascript.html
>
> following is what you need to do ..
>
> you can concatenate the value you want to return as paramter in
> callbackurl,we will read this back as request
> parameter from java.
>
> it should look like callbackurl+"&"+component markupid+"="+args;
>
> then in your respond method you can easily read request parameter from url .
> String paramFoo = RequestCycle.get().getRequest().getParameter("component
> markupid");
>
>
> On Fri, Mar 19, 2010 at 7:51 PM, Stefan Lindner <li...@visionet.de> wrote:
>
>> If I place a call to wicketAjaxGet(...) into a eg.g onclick attribute
>> with the help of an AjaxBehavior, the method respond(final
>> AjaxRequestTarget target) is called on the Java side.
>>
>> Is it possible to build a call to wicketAjaxGet like
>>
>> var result = wicketAjaxGet(...);
>>
>> and provid the result value in the respond method on the Java side?
>>
>> Does anobody know the trick?
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> regards,
> Vineet Semwal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to return a result value for wicketAjaxGet
Posted by Igor Vaynberg <ig...@gmail.com>.
append the name of the variable to the url, in target generate js that
sets the variable to the value. after wicketajaxget processes the
result the value should be set
-igor
On Fri, Mar 19, 2010 at 8:52 AM, Stefan Lindner <li...@visionet.de> wrote:
> Hi Vineet,
>
> that's true. I already know this but this is not what I need. I need the opposite thing. What you explained is something like an input parameter to wicketAjaxGet. This input parameters can easily be fetches from the Request.
>
> But what I need is a return value for wicketAjaxGet. That is visible in the javascript code AFTER doing something in respond.
>
> This means
>
>
> Have some javascript on the page like
>
> var result = wicketAjaxGet(...)&someParameter...;
> // do the respond() mehtod processing on the javaside and return a value
> alert('result of respond processing' = result);
>
> Stefan
>
> -----Ursprüngliche Nachricht-----
> Von: vineet semwal [mailto:vineetsemwal1982@gmail.com]
> Gesendet: Freitag, 19. März 2010 16:34
> An: users@wicket.apache.org
> Betreff: Re: How to return a result value for wicketAjaxGet
>
> Hi,
> take a look at
> http://cwiki.apache.org/WICKET/calling-wicket-from-javascript.html
>
> following is what you need to do ..
>
> you can concatenate the value you want to return as paramter in
> callbackurl,we will read this back as request
> parameter from java.
>
> it should look like callbackurl+"&"+component markupid+"="+args;
>
> then in your respond method you can easily read request parameter from url .
> String paramFoo = RequestCycle.get().getRequest().getParameter("component
> markupid");
>
>
> On Fri, Mar 19, 2010 at 7:51 PM, Stefan Lindner <li...@visionet.de> wrote:
>
>> If I place a call to wicketAjaxGet(...) into a eg.g onclick attribute
>> with the help of an AjaxBehavior, the method respond(final
>> AjaxRequestTarget target) is called on the Java side.
>>
>> Is it possible to build a call to wicketAjaxGet like
>>
>> var result = wicketAjaxGet(...);
>>
>> and provid the result value in the respond method on the Java side?
>>
>> Does anobody know the trick?
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> regards,
> Vineet Semwal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
AW: How to return a result value for wicketAjaxGet
Posted by Stefan Lindner <li...@visionet.de>.
Hi Vineet,
that's true. I already know this but this is not what I need. I need the opposite thing. What you explained is something like an input parameter to wicketAjaxGet. This input parameters can easily be fetches from the Request.
But what I need is a return value for wicketAjaxGet. That is visible in the javascript code AFTER doing something in respond.
This means
Have some javascript on the page like
var result = wicketAjaxGet(...)&someParameter...;
// do the respond() mehtod processing on the javaside and return a value
alert('result of respond processing' = result);
Stefan
-----Ursprüngliche Nachricht-----
Von: vineet semwal [mailto:vineetsemwal1982@gmail.com]
Gesendet: Freitag, 19. März 2010 16:34
An: users@wicket.apache.org
Betreff: Re: How to return a result value for wicketAjaxGet
Hi,
take a look at
http://cwiki.apache.org/WICKET/calling-wicket-from-javascript.html
following is what you need to do ..
you can concatenate the value you want to return as paramter in
callbackurl,we will read this back as request
parameter from java.
it should look like callbackurl+"&"+component markupid+"="+args;
then in your respond method you can easily read request parameter from url .
String paramFoo = RequestCycle.get().getRequest().getParameter("component
markupid");
On Fri, Mar 19, 2010 at 7:51 PM, Stefan Lindner <li...@visionet.de> wrote:
> If I place a call to wicketAjaxGet(...) into a eg.g onclick attribute
> with the help of an AjaxBehavior, the method respond(final
> AjaxRequestTarget target) is called on the Java side.
>
> Is it possible to build a call to wicketAjaxGet like
>
> var result = wicketAjaxGet(...);
>
> and provid the result value in the respond method on the Java side?
>
> Does anobody know the trick?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
regards,
Vineet Semwal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How to return a result value for wicketAjaxGet
Posted by vineet semwal <vi...@gmail.com>.
Hi,
take a look at
http://cwiki.apache.org/WICKET/calling-wicket-from-javascript.html
following is what you need to do ..
you can concatenate the value you want to return as paramter in
callbackurl,we will read this back as request
parameter from java.
it should look like callbackurl+"&"+component markupid+"="+args;
then in your respond method you can easily read request parameter from url .
String paramFoo = RequestCycle.get().getRequest().getParameter("component
markupid");
On Fri, Mar 19, 2010 at 7:51 PM, Stefan Lindner <li...@visionet.de> wrote:
> If I place a call to wicketAjaxGet(...) into a eg.g onclick attribute
> with the help of an AjaxBehavior, the method respond(final
> AjaxRequestTarget target) is called on the Java side.
>
> Is it possible to build a call to wicketAjaxGet like
>
> var result = wicketAjaxGet(...);
>
> and provid the result value in the respond method on the Java side?
>
> Does anobody know the trick?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
regards,
Vineet Semwal
How to construct/generate AjaxRequestTarget for a WebPage, without
explicitly being fired from AjaxButton/AjaxLink/AjaxSelfUpdatingTimerBehavior
Posted by Martin Asenov <mA...@velti.com>.
To me modalWindow.close(new AjaxRequestTarget(containerPage)) doesn't work...
And RequestCycle.get().getRequestTarget() returns null;
Please help...
Best,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
How to return a result value for wicketAjaxGet
Posted by Stefan Lindner <li...@visionet.de>.
If I place a call to wicketAjaxGet(...) into a eg.g onclick attribute
with the help of an AjaxBehavior, the method respond(final
AjaxRequestTarget target) is called on the Java side.
Is it possible to build a call to wicketAjaxGet like
var result = wicketAjaxGet(...);
and provid the result value in the respond method on the Java side?
Does anobody know the trick?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by nino martinez wael <ni...@gmail.com>.
Usual process for wicket are to let trunk follow current release, when
switching major build number ie from 1.3 -> 1.4 then make a branch for
the old version I suggest we do the same..?
And yeah just upgrade the dependencies :) Unless someone disagree.
-N
2010/3/23 Boris Goldowsky <bg...@cast.org>:
> I think this sounds good, and meshes with the comments several other people
> have made. So I think we're converging on a general agreement for a
> process. Documenting it on the wiki would be great.
>
> If there are no objections, I can take the first step in this process, which
> would seem to be setting wicketstuff-core's dependency to wicket 1.4.7, and
> then asking people to test it. We should probably set a date by which we
> ask people to test out the modules they use -- otherwise if no issues are
> reported we won't know when to declare the testing period over and actually
> do the release.
>
> How do people feel about the other dependencies in there (jetty, slf4j,
> etc)? Should we just as a matter of course re-point those to the latest
> stable versions when we do a version bump of wicket and are heading into a
> round of testing?
>
> Bng
>
>
>
> Michael O'Cleirigh wrote:
>>
>> Hello,
>>
>> I'd like the trunk to follow the latest wicket release since when
>> wicketstuff-core is released it is meant to be paired with the current
>> wicket release. i.e. not 1.4-SNAPSHOT but 1.4.7, 1.4.8, 1.4.9 and eventually
>> into 1.5RC1, etc.
>>
>> Envisioned Process for 1.4.8 Wicket Release:
>> 1. wicket releases new version 1.4.8
>> 2. wicketstuff-core pom is updated for 1.4.8
>> 3. organized testing and vote on release.
>> 4. release (non SNAPSHOT) artifacts are generated and pushed into maven
>> and a svn:/tags/wicketstuff-core-1.4.8 tag is created
>> 5. trunk pom's are changed back to wicketstuff-core version of
>> 1.4-SNAPSHOT
>>
>> I think we should only cut one release per wicket main release and any
>> other changes just go automatically into the 1.4-SNAPSHOT releases that are
>> generated when a developer commits. If a user needs new features in the gap
>> between releases they can just get the SNAPSHOT releases.
>>
>> +1 for creating a svn:/branches/wicketstuff-core-1.4 when trunk switches
>> to the 1.5 RC's. We can then support two release lines but everying is tied
>> to wicket main releases. When wicket end of life's the 1.4.x line there
>> will be no more releases just snapshots. Also there should be no developer
>> requirement to sync the 1.4 and 1.5 branch project contents (i.e. supporting
>> two lines) just maintenance on 1.4 branch and new development on trunk.
>>
>> +1 on creating wicketstuff-core jira to coordinate release process.
>>
>> +1 on creating a wicketstuff-core/wicketstuff-test module to share testing
>> code between core projects.
>>
>> +1 on running integration tests to find run-time issues before release on
>> the generated project artifacts (i.e. like selenium through maven
>> integration-test phase). I know this is hard but maybe a special profile in
>> the pom to allow these extended quality checks to be run outside of a
>> continuous integration environment prior to release.
>>
>> +1 improving the wicketstuff developer wiki with details on how the
>> release process works (I'm volunteering)
>>
>> Regards,
>>
>> Mike
>>
>>> Id vote for this one:
>>>
>>> modify the trunk
>>> first for 1.4.7 fix the incompatibilities if there are, and then release
>>> it as 1.4.7 and make trunk to follow 1.4-SNAPSHOT?
>>>
>>> And if you like sonar, it's opensource and requires almost no setup it
>>> has a fluent plugin with maven. For example theres a pretty good
>>> integration between hudson, I could'nt find one for team city though
>>> :/ But in theory it's just running the mvn command sonar:sonar..
>>>
>>> 2010/3/23 Major Péter<ma...@sch.bme.hu>:
>>>
>>>>
>>>> Tests are good, but this could be also arranged with voting, or not?
>>>> So what would be the best?
>>>> Modify the trunk to use 1.4.7, and release the current state as
>>>> wicketstuff 1.4.1 (because it's using 1.4.1 now) or modify the trunk
>>>> first for 1.4.7 fix the incompatibilities if there are, and then release
>>>> it as 1.4.7 and make trunk to follow 1.4-SNAPSHOT?
>>>> Or what else do you have in mind?
>>>> This sonarsource is good stuff, +1.
>>>>
>>>> Peter
>>>>
>>>> 2010-03-23 12:33 keltezéssel, nino martinez wael írta:
>>>>
>>>>>
>>>>> +1 for me on upgrading wicketstuff core to 1.4.7.
>>>>>
>>>>> On another topic making sure that an upgrade actually works are
>>>>> another thing. Code might compile but there could be runtime
>>>>> problems.. I discussed looong time ago a possibility for making tests
>>>>> for the javascript parts of the code aswell, with rhino... We could'nt
>>>>> really call it stable until we made sure it where that. On another
>>>>> node I'd suggest adding wicketstuff core to nemo.sonarsource.org , as
>>>>> it would help showing code metrics etc..
>>>>>
>>>>> 2010/3/23 Stefan Lindner<li...@visionet.de>:
>>>>>
>>>>>>
>>>>>> Should we really start with a big bang? Support wicketstuff STABLE
>>>>>> core releases for Wicket 1.4 AND 1.5RCx? Is a RC for Wicket 1.5 in sight? Or
>>>>>> does this mean everything in wicketstuff will stay as it is for a long time?
>>>>>> Why not start with a smaller step and create a core wicketstuff
>>>>>> release for current wicket 1.4?
>>>>>>
>>>>>> Stefan
>>>>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: Major Péter [mailto:majorpetya@sch.bme.hu]
>>>>>> Gesendet: Dienstag, 23. März 2010 11:38
>>>>>> An: users@wicket.apache.org
>>>>>> Betreff: Re: Wicketstuff versioning
>>>>>>
>>>>>> 2010-03-23 11:24 keltezéssel, Boris Goldowsky írta:
>>>>>>
>>>>>>>
>>>>>>> I may be wrong, but wouldn't it make sense to delay creating a 1.4.x
>>>>>>> branch until/unless someone actually wants to commit some code that
>>>>>>> would be different for 1.4.x and 1.5-SNAPSHOT? Once we branch, we
>>>>>>> have
>>>>>>> to start committing every bug fix to two different versions, right?
>>>>>>>
>>>>>>
>>>>>> Yes, you're right about this, maybe we should wait until the first 1.5
>>>>>> RC with it.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> If we're lucky, everything in Wicketstuff may work fine unchanged
>>>>>>> with
>>>>>>> 1.4 and 1.5, and I suggest we can save ourselves a large amount of
>>>>>>> headache by just maintaining a single trunk, and bumping the version
>>>>>>> after there's an official Wicket release.
>>>>>>>
>>>>>>
>>>>>> As far as I saw, there was some major modifications in the core around
>>>>>> the request-handling and URL-strategies, so this could rise up some
>>>>>> issues.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Of course, correct me if I'm wrong. I don't know how fundamentally
>>>>>>> different wicket 1.5 is going to be, or if there are a lot of people
>>>>>>> running snapshots of it now who would need Wicketstuff to be tracking
>>>>>>> it.
>>>>>>>
>>>>>>
>>>>>> Is 1.5 RC1 good for everyone? :)
>>>>>>
>>>>>> Regards,
>>>>>> Peter
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by nino martinez wael <ni...@gmail.com>.
> Yes, confluence is great, but a bit of useless since the spam-incident.
> I think the confluence is still full of with spammer users and
> spamcontents. Also the registration doesn't work, but this is an another
> issue. Nino, if I remember correctly, you can access confluence, right?
> Could you do something with these?
Yeah can acess confluence, but there are A LOT of spammer users, and I
gave up deleting them last time after using ½ an hour. I think it
would be easier using a sql connection and droping the spammer users
through there. What are you suggesting?
>
> Also TeamCity is failing lately, since there is some network error, and
> it cannot access the svn (Connection refused).
Hmmm we had that problem with bamboo too :/ Im not sure it's the same though..
2010/3/23 Major Péter <ma...@sch.bme.hu>:
> Hi,
>
>> +1 on creating wicketstuff-core jira to coordinate release process.
>
> Here it is: http://wicketstuff.org/jira/secure/Dashboard.jspa
>
>> +1 on creating a wicketstuff-core/wicketstuff-test module to share
>> testing code between core projects.
>>
>> +1 on running integration tests to find run-time issues before release
>> on the generated project artifacts (i.e. like selenium through maven
>> integration-test phase). I know this is hard but maybe a special
>> profile in the pom to allow these extended quality checks to be run
>> outside of a continuous integration environment prior to release.
>
> This testing would be really great, but I think this is more of a dream,
> rather then a real purpose right now. The project maintainers are doing
> their work in their freetime, making them mandatory to create testcases,
> may scare them, because they don't have the time to maintain those too.
>
>> +1 improving the wicketstuff developer wiki with details on how the
>> release process works (I'm volunteering)
>
> Yes, confluence is great, but a bit of useless since the spam-incident.
> I think the confluence is still full of with spammer users and
> spamcontents. Also the registration doesn't work, but this is an another
> issue. Nino, if I remember correctly, you can access confluence, right?
> Could you do something with these?
>
> Also TeamCity is failing lately, since there is some network error, and
> it cannot access the svn (Connection refused).
>
> Thanks,
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Major Péter <ma...@sch.bme.hu>.
Hi,
> +1 on creating wicketstuff-core jira to coordinate release process.
Here it is: http://wicketstuff.org/jira/secure/Dashboard.jspa
> +1 on creating a wicketstuff-core/wicketstuff-test module to share
> testing code between core projects.
>
> +1 on running integration tests to find run-time issues before release
> on the generated project artifacts (i.e. like selenium through maven
> integration-test phase). I know this is hard but maybe a special
> profile in the pom to allow these extended quality checks to be run
> outside of a continuous integration environment prior to release.
This testing would be really great, but I think this is more of a dream,
rather then a real purpose right now. The project maintainers are doing
their work in their freetime, making them mandatory to create testcases,
may scare them, because they don't have the time to maintain those too.
> +1 improving the wicketstuff developer wiki with details on how the
> release process works (I'm volunteering)
Yes, confluence is great, but a bit of useless since the spam-incident.
I think the confluence is still full of with spammer users and
spamcontents. Also the registration doesn't work, but this is an another
issue. Nino, if I remember correctly, you can access confluence, right?
Could you do something with these?
Also TeamCity is failing lately, since there is some network error, and
it cannot access the svn (Connection refused).
Thanks,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Boris Goldowsky <bg...@cast.org>.
I think this sounds good, and meshes with the comments several other
people have made. So I think we're converging on a general agreement
for a process. Documenting it on the wiki would be great.
If there are no objections, I can take the first step in this process,
which would seem to be setting wicketstuff-core's dependency to wicket
1.4.7, and then asking people to test it. We should probably set a date
by which we ask people to test out the modules they use -- otherwise if
no issues are reported we won't know when to declare the testing period
over and actually do the release.
How do people feel about the other dependencies in there (jetty, slf4j,
etc)? Should we just as a matter of course re-point those to the latest
stable versions when we do a version bump of wicket and are heading into
a round of testing?
Bng
Michael O'Cleirigh wrote:
> Hello,
>
> I'd like the trunk to follow the latest wicket release since when
> wicketstuff-core is released it is meant to be paired with the current
> wicket release. i.e. not 1.4-SNAPSHOT but 1.4.7, 1.4.8, 1.4.9 and
> eventually into 1.5RC1, etc.
>
> Envisioned Process for 1.4.8 Wicket Release:
> 1. wicket releases new version 1.4.8
> 2. wicketstuff-core pom is updated for 1.4.8
> 3. organized testing and vote on release.
> 4. release (non SNAPSHOT) artifacts are generated and pushed into
> maven and a svn:/tags/wicketstuff-core-1.4.8 tag is created
> 5. trunk pom's are changed back to wicketstuff-core version of
> 1.4-SNAPSHOT
>
> I think we should only cut one release per wicket main release and any
> other changes just go automatically into the 1.4-SNAPSHOT releases
> that are generated when a developer commits. If a user needs new
> features in the gap between releases they can just get the SNAPSHOT
> releases.
>
> +1 for creating a svn:/branches/wicketstuff-core-1.4 when trunk
> switches to the 1.5 RC's. We can then support two release lines but
> everying is tied to wicket main releases. When wicket end of life's
> the 1.4.x line there will be no more releases just snapshots. Also
> there should be no developer requirement to sync the 1.4 and 1.5
> branch project contents (i.e. supporting two lines) just maintenance
> on 1.4 branch and new development on trunk.
>
> +1 on creating wicketstuff-core jira to coordinate release process.
>
> +1 on creating a wicketstuff-core/wicketstuff-test module to share
> testing code between core projects.
>
> +1 on running integration tests to find run-time issues before release
> on the generated project artifacts (i.e. like selenium through maven
> integration-test phase). I know this is hard but maybe a special
> profile in the pom to allow these extended quality checks to be run
> outside of a continuous integration environment prior to release.
>
> +1 improving the wicketstuff developer wiki with details on how the
> release process works (I'm volunteering)
>
> Regards,
>
> Mike
>
>> Id vote for this one:
>>
>> modify the trunk
>> first for 1.4.7 fix the incompatibilities if there are, and then release
>> it as 1.4.7 and make trunk to follow 1.4-SNAPSHOT?
>>
>> And if you like sonar, it's opensource and requires almost no setup it
>> has a fluent plugin with maven. For example theres a pretty good
>> integration between hudson, I could'nt find one for team city though
>> :/ But in theory it's just running the mvn command sonar:sonar..
>>
>> 2010/3/23 Major Péter<ma...@sch.bme.hu>:
>>
>>> Tests are good, but this could be also arranged with voting, or not?
>>> So what would be the best?
>>> Modify the trunk to use 1.4.7, and release the current state as
>>> wicketstuff 1.4.1 (because it's using 1.4.1 now) or modify the trunk
>>> first for 1.4.7 fix the incompatibilities if there are, and then
>>> release
>>> it as 1.4.7 and make trunk to follow 1.4-SNAPSHOT?
>>> Or what else do you have in mind?
>>> This sonarsource is good stuff, +1.
>>>
>>> Peter
>>>
>>> 2010-03-23 12:33 keltezéssel, nino martinez wael írta:
>>>
>>>> +1 for me on upgrading wicketstuff core to 1.4.7.
>>>>
>>>> On another topic making sure that an upgrade actually works are
>>>> another thing. Code might compile but there could be runtime
>>>> problems.. I discussed looong time ago a possibility for making tests
>>>> for the javascript parts of the code aswell, with rhino... We could'nt
>>>> really call it stable until we made sure it where that. On another
>>>> node I'd suggest adding wicketstuff core to nemo.sonarsource.org , as
>>>> it would help showing code metrics etc..
>>>>
>>>> 2010/3/23 Stefan Lindner<li...@visionet.de>:
>>>>
>>>>> Should we really start with a big bang? Support wicketstuff STABLE
>>>>> core releases for Wicket 1.4 AND 1.5RCx? Is a RC for Wicket 1.5 in
>>>>> sight? Or does this mean everything in wicketstuff will stay as it
>>>>> is for a long time?
>>>>> Why not start with a smaller step and create a core wicketstuff
>>>>> release for current wicket 1.4?
>>>>>
>>>>> Stefan
>>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: Major Péter [mailto:majorpetya@sch.bme.hu]
>>>>> Gesendet: Dienstag, 23. März 2010 11:38
>>>>> An: users@wicket.apache.org
>>>>> Betreff: Re: Wicketstuff versioning
>>>>>
>>>>> 2010-03-23 11:24 keltezéssel, Boris Goldowsky írta:
>>>>>
>>>>>> I may be wrong, but wouldn't it make sense to delay creating a 1.4.x
>>>>>> branch until/unless someone actually wants to commit some code that
>>>>>> would be different for 1.4.x and 1.5-SNAPSHOT? Once we branch,
>>>>>> we have
>>>>>> to start committing every bug fix to two different versions, right?
>>>>>>
>>>>> Yes, you're right about this, maybe we should wait until the first
>>>>> 1.5
>>>>> RC with it.
>>>>>
>>>>>
>>>>>> If we're lucky, everything in Wicketstuff may work fine unchanged
>>>>>> with
>>>>>> 1.4 and 1.5, and I suggest we can save ourselves a large amount of
>>>>>> headache by just maintaining a single trunk, and bumping the version
>>>>>> after there's an official Wicket release.
>>>>>>
>>>>> As far as I saw, there was some major modifications in the core
>>>>> around
>>>>> the request-handling and URL-strategies, so this could rise up
>>>>> some issues.
>>>>>
>>>>>
>>>>>> Of course, correct me if I'm wrong. I don't know how fundamentally
>>>>>> different wicket 1.5 is going to be, or if there are a lot of people
>>>>>> running snapshots of it now who would need Wicketstuff to be
>>>>>> tracking
>>>>>> it.
>>>>>>
>>>>> Is 1.5 RC1 good for everyone? :)
>>>>>
>>>>> Regards,
>>>>> Peter
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Michael O'Cleirigh <mi...@rivulet.ca>.
Hello,
I'd like the trunk to follow the latest wicket release since when
wicketstuff-core is released it is meant to be paired with the current
wicket release. i.e. not 1.4-SNAPSHOT but 1.4.7, 1.4.8, 1.4.9 and
eventually into 1.5RC1, etc.
Envisioned Process for 1.4.8 Wicket Release:
1. wicket releases new version 1.4.8
2. wicketstuff-core pom is updated for 1.4.8
3. organized testing and vote on release.
4. release (non SNAPSHOT) artifacts are generated and pushed into maven
and a svn:/tags/wicketstuff-core-1.4.8 tag is created
5. trunk pom's are changed back to wicketstuff-core version of 1.4-SNAPSHOT
I think we should only cut one release per wicket main release and any
other changes just go automatically into the 1.4-SNAPSHOT releases that
are generated when a developer commits. If a user needs new features in
the gap between releases they can just get the SNAPSHOT releases.
+1 for creating a svn:/branches/wicketstuff-core-1.4 when trunk switches
to the 1.5 RC's. We can then support two release lines but everying is
tied to wicket main releases. When wicket end of life's the 1.4.x line
there will be no more releases just snapshots. Also there should be no
developer requirement to sync the 1.4 and 1.5 branch project contents
(i.e. supporting two lines) just maintenance on 1.4 branch and new
development on trunk.
+1 on creating wicketstuff-core jira to coordinate release process.
+1 on creating a wicketstuff-core/wicketstuff-test module to share
testing code between core projects.
+1 on running integration tests to find run-time issues before release
on the generated project artifacts (i.e. like selenium through maven
integration-test phase). I know this is hard but maybe a special
profile in the pom to allow these extended quality checks to be run
outside of a continuous integration environment prior to release.
+1 improving the wicketstuff developer wiki with details on how the
release process works (I'm volunteering)
Regards,
Mike
> Id vote for this one:
>
> modify the trunk
> first for 1.4.7 fix the incompatibilities if there are, and then release
> it as 1.4.7 and make trunk to follow 1.4-SNAPSHOT?
>
> And if you like sonar, it's opensource and requires almost no setup it
> has a fluent plugin with maven. For example theres a pretty good
> integration between hudson, I could'nt find one for team city though
> :/ But in theory it's just running the mvn command sonar:sonar..
>
> 2010/3/23 Major Péter<ma...@sch.bme.hu>:
>
>> Tests are good, but this could be also arranged with voting, or not?
>> So what would be the best?
>> Modify the trunk to use 1.4.7, and release the current state as
>> wicketstuff 1.4.1 (because it's using 1.4.1 now) or modify the trunk
>> first for 1.4.7 fix the incompatibilities if there are, and then release
>> it as 1.4.7 and make trunk to follow 1.4-SNAPSHOT?
>> Or what else do you have in mind?
>> This sonarsource is good stuff, +1.
>>
>> Peter
>>
>> 2010-03-23 12:33 keltezéssel, nino martinez wael írta:
>>
>>> +1 for me on upgrading wicketstuff core to 1.4.7.
>>>
>>> On another topic making sure that an upgrade actually works are
>>> another thing. Code might compile but there could be runtime
>>> problems.. I discussed looong time ago a possibility for making tests
>>> for the javascript parts of the code aswell, with rhino... We could'nt
>>> really call it stable until we made sure it where that. On another
>>> node I'd suggest adding wicketstuff core to nemo.sonarsource.org , as
>>> it would help showing code metrics etc..
>>>
>>> 2010/3/23 Stefan Lindner<li...@visionet.de>:
>>>
>>>> Should we really start with a big bang? Support wicketstuff STABLE core releases for Wicket 1.4 AND 1.5RCx? Is a RC for Wicket 1.5 in sight? Or does this mean everything in wicketstuff will stay as it is for a long time?
>>>> Why not start with a smaller step and create a core wicketstuff release for current wicket 1.4?
>>>>
>>>> Stefan
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Major Péter [mailto:majorpetya@sch.bme.hu]
>>>> Gesendet: Dienstag, 23. März 2010 11:38
>>>> An: users@wicket.apache.org
>>>> Betreff: Re: Wicketstuff versioning
>>>>
>>>> 2010-03-23 11:24 keltezéssel, Boris Goldowsky írta:
>>>>
>>>>> I may be wrong, but wouldn't it make sense to delay creating a 1.4.x
>>>>> branch until/unless someone actually wants to commit some code that
>>>>> would be different for 1.4.x and 1.5-SNAPSHOT? Once we branch, we have
>>>>> to start committing every bug fix to two different versions, right?
>>>>>
>>>> Yes, you're right about this, maybe we should wait until the first 1.5
>>>> RC with it.
>>>>
>>>>
>>>>> If we're lucky, everything in Wicketstuff may work fine unchanged with
>>>>> 1.4 and 1.5, and I suggest we can save ourselves a large amount of
>>>>> headache by just maintaining a single trunk, and bumping the version
>>>>> after there's an official Wicket release.
>>>>>
>>>> As far as I saw, there was some major modifications in the core around
>>>> the request-handling and URL-strategies, so this could rise up some issues.
>>>>
>>>>
>>>>> Of course, correct me if I'm wrong. I don't know how fundamentally
>>>>> different wicket 1.5 is going to be, or if there are a lot of people
>>>>> running snapshots of it now who would need Wicketstuff to be tracking
>>>>> it.
>>>>>
>>>> Is 1.5 RC1 good for everyone? :)
>>>>
>>>> Regards,
>>>> Peter
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by nino martinez wael <ni...@gmail.com>.
Id vote for this one:
modify the trunk
first for 1.4.7 fix the incompatibilities if there are, and then release
it as 1.4.7 and make trunk to follow 1.4-SNAPSHOT?
And if you like sonar, it's opensource and requires almost no setup it
has a fluent plugin with maven. For example theres a pretty good
integration between hudson, I could'nt find one for team city though
:/ But in theory it's just running the mvn command sonar:sonar..
2010/3/23 Major Péter <ma...@sch.bme.hu>:
> Tests are good, but this could be also arranged with voting, or not?
> So what would be the best?
> Modify the trunk to use 1.4.7, and release the current state as
> wicketstuff 1.4.1 (because it's using 1.4.1 now) or modify the trunk
> first for 1.4.7 fix the incompatibilities if there are, and then release
> it as 1.4.7 and make trunk to follow 1.4-SNAPSHOT?
> Or what else do you have in mind?
> This sonarsource is good stuff, +1.
>
> Peter
>
> 2010-03-23 12:33 keltezéssel, nino martinez wael írta:
>> +1 for me on upgrading wicketstuff core to 1.4.7.
>>
>> On another topic making sure that an upgrade actually works are
>> another thing. Code might compile but there could be runtime
>> problems.. I discussed looong time ago a possibility for making tests
>> for the javascript parts of the code aswell, with rhino... We could'nt
>> really call it stable until we made sure it where that. On another
>> node I'd suggest adding wicketstuff core to nemo.sonarsource.org , as
>> it would help showing code metrics etc..
>>
>> 2010/3/23 Stefan Lindner <li...@visionet.de>:
>>> Should we really start with a big bang? Support wicketstuff STABLE core releases for Wicket 1.4 AND 1.5RCx? Is a RC for Wicket 1.5 in sight? Or does this mean everything in wicketstuff will stay as it is for a long time?
>>> Why not start with a smaller step and create a core wicketstuff release for current wicket 1.4?
>>>
>>> Stefan
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Major Péter [mailto:majorpetya@sch.bme.hu]
>>> Gesendet: Dienstag, 23. März 2010 11:38
>>> An: users@wicket.apache.org
>>> Betreff: Re: Wicketstuff versioning
>>>
>>> 2010-03-23 11:24 keltezéssel, Boris Goldowsky írta:
>>>> I may be wrong, but wouldn't it make sense to delay creating a 1.4.x
>>>> branch until/unless someone actually wants to commit some code that
>>>> would be different for 1.4.x and 1.5-SNAPSHOT? Once we branch, we have
>>>> to start committing every bug fix to two different versions, right?
>>>
>>> Yes, you're right about this, maybe we should wait until the first 1.5
>>> RC with it.
>>>
>>>> If we're lucky, everything in Wicketstuff may work fine unchanged with
>>>> 1.4 and 1.5, and I suggest we can save ourselves a large amount of
>>>> headache by just maintaining a single trunk, and bumping the version
>>>> after there's an official Wicket release.
>>>
>>> As far as I saw, there was some major modifications in the core around
>>> the request-handling and URL-strategies, so this could rise up some issues.
>>>
>>>> Of course, correct me if I'm wrong. I don't know how fundamentally
>>>> different wicket 1.5 is going to be, or if there are a lot of people
>>>> running snapshots of it now who would need Wicketstuff to be tracking
>>>> it.
>>>
>>> Is 1.5 RC1 good for everyone? :)
>>>
>>> Regards,
>>> Peter
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Major Péter <ma...@sch.bme.hu>.
Tests are good, but this could be also arranged with voting, or not?
So what would be the best?
Modify the trunk to use 1.4.7, and release the current state as
wicketstuff 1.4.1 (because it's using 1.4.1 now) or modify the trunk
first for 1.4.7 fix the incompatibilities if there are, and then release
it as 1.4.7 and make trunk to follow 1.4-SNAPSHOT?
Or what else do you have in mind?
This sonarsource is good stuff, +1.
Peter
2010-03-23 12:33 keltezéssel, nino martinez wael írta:
> +1 for me on upgrading wicketstuff core to 1.4.7.
>
> On another topic making sure that an upgrade actually works are
> another thing. Code might compile but there could be runtime
> problems.. I discussed looong time ago a possibility for making tests
> for the javascript parts of the code aswell, with rhino... We could'nt
> really call it stable until we made sure it where that. On another
> node I'd suggest adding wicketstuff core to nemo.sonarsource.org , as
> it would help showing code metrics etc..
>
> 2010/3/23 Stefan Lindner <li...@visionet.de>:
>> Should we really start with a big bang? Support wicketstuff STABLE core releases for Wicket 1.4 AND 1.5RCx? Is a RC for Wicket 1.5 in sight? Or does this mean everything in wicketstuff will stay as it is for a long time?
>> Why not start with a smaller step and create a core wicketstuff release for current wicket 1.4?
>>
>> Stefan
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Major Péter [mailto:majorpetya@sch.bme.hu]
>> Gesendet: Dienstag, 23. März 2010 11:38
>> An: users@wicket.apache.org
>> Betreff: Re: Wicketstuff versioning
>>
>> 2010-03-23 11:24 keltezéssel, Boris Goldowsky írta:
>>> I may be wrong, but wouldn't it make sense to delay creating a 1.4.x
>>> branch until/unless someone actually wants to commit some code that
>>> would be different for 1.4.x and 1.5-SNAPSHOT? Once we branch, we have
>>> to start committing every bug fix to two different versions, right?
>>
>> Yes, you're right about this, maybe we should wait until the first 1.5
>> RC with it.
>>
>>> If we're lucky, everything in Wicketstuff may work fine unchanged with
>>> 1.4 and 1.5, and I suggest we can save ourselves a large amount of
>>> headache by just maintaining a single trunk, and bumping the version
>>> after there's an official Wicket release.
>>
>> As far as I saw, there was some major modifications in the core around
>> the request-handling and URL-strategies, so this could rise up some issues.
>>
>>> Of course, correct me if I'm wrong. I don't know how fundamentally
>>> different wicket 1.5 is going to be, or if there are a lot of people
>>> running snapshots of it now who would need Wicketstuff to be tracking
>>> it.
>>
>> Is 1.5 RC1 good for everyone? :)
>>
>> Regards,
>> Peter
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by nino martinez wael <ni...@gmail.com>.
+1 for me on upgrading wicketstuff core to 1.4.7.
On another topic making sure that an upgrade actually works are
another thing. Code might compile but there could be runtime
problems.. I discussed looong time ago a possibility for making tests
for the javascript parts of the code aswell, with rhino... We could'nt
really call it stable until we made sure it where that. On another
node I'd suggest adding wicketstuff core to nemo.sonarsource.org , as
it would help showing code metrics etc..
2010/3/23 Stefan Lindner <li...@visionet.de>:
> Should we really start with a big bang? Support wicketstuff STABLE core releases for Wicket 1.4 AND 1.5RCx? Is a RC for Wicket 1.5 in sight? Or does this mean everything in wicketstuff will stay as it is for a long time?
> Why not start with a smaller step and create a core wicketstuff release for current wicket 1.4?
>
> Stefan
>
> -----Ursprüngliche Nachricht-----
> Von: Major Péter [mailto:majorpetya@sch.bme.hu]
> Gesendet: Dienstag, 23. März 2010 11:38
> An: users@wicket.apache.org
> Betreff: Re: Wicketstuff versioning
>
> 2010-03-23 11:24 keltezéssel, Boris Goldowsky írta:
>> I may be wrong, but wouldn't it make sense to delay creating a 1.4.x
>> branch until/unless someone actually wants to commit some code that
>> would be different for 1.4.x and 1.5-SNAPSHOT? Once we branch, we have
>> to start committing every bug fix to two different versions, right?
>
> Yes, you're right about this, maybe we should wait until the first 1.5
> RC with it.
>
>> If we're lucky, everything in Wicketstuff may work fine unchanged with
>> 1.4 and 1.5, and I suggest we can save ourselves a large amount of
>> headache by just maintaining a single trunk, and bumping the version
>> after there's an official Wicket release.
>
> As far as I saw, there was some major modifications in the core around
> the request-handling and URL-strategies, so this could rise up some issues.
>
>> Of course, correct me if I'm wrong. I don't know how fundamentally
>> different wicket 1.5 is going to be, or if there are a lot of people
>> running snapshots of it now who would need Wicketstuff to be tracking
>> it.
>
> Is 1.5 RC1 good for everyone? :)
>
> Regards,
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Nicolai Guba <ng...@mac.com>.
1.5 rc only makes sense if it is not compatible with 1.4 any longer.
Otherwise 1.4 makes better sense to me ;)
Sent from my iPhone
On 23 Mar 2010, at 10:45, Stefan Lindner <li...@visionet.de> wrote:
> Should we really start with a big bang? Support wicketstuff STABLE
> core releases for Wicket 1.4 AND 1.5RCx? Is a RC for Wicket 1.5 in
> sight? Or does this mean everything in wicketstuff will stay as it
> is for a long time?
> Why not start with a smaller step and create a core wicketstuff
> release for current wicket 1.4?
>
> Stefan
>
> -----Ursprüngliche Nachricht-----
> Von: Major Péter [mailto:majorpetya@sch.bme.hu]
> Gesendet: Dienstag, 23. März 2010 11:38
> An: users@wicket.apache.org
> Betreff: Re: Wicketstuff versioning
>
> 2010-03-23 11:24 keltezéssel, Boris Goldowsky írta:
>> I may be wrong, but wouldn't it make sense to delay creating a 1.4.x
>> branch until/unless someone actually wants to commit some code that
>> would be different for 1.4.x and 1.5-SNAPSHOT? Once we branch, we
>> have
>> to start committing every bug fix to two different versions, right?
>
> Yes, you're right about this, maybe we should wait until the first 1.5
> RC with it.
>
>> If we're lucky, everything in Wicketstuff may work fine unchanged
>> with
>> 1.4 and 1.5, and I suggest we can save ourselves a large amount of
>> headache by just maintaining a single trunk, and bumping the version
>> after there's an official Wicket release.
>
> As far as I saw, there was some major modifications in the core around
> the request-handling and URL-strategies, so this could rise up some
> issues.
>
>> Of course, correct me if I'm wrong. I don't know how fundamentally
>> different wicket 1.5 is going to be, or if there are a lot of people
>> running snapshots of it now who would need Wicketstuff to be tracking
>> it.
>
> Is 1.5 RC1 good for everyone? :)
>
> Regards,
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Wicketstuff versioning
Posted by Stefan Lindner <li...@visionet.de>.
Should we really start with a big bang? Support wicketstuff STABLE core releases for Wicket 1.4 AND 1.5RCx? Is a RC for Wicket 1.5 in sight? Or does this mean everything in wicketstuff will stay as it is for a long time?
Why not start with a smaller step and create a core wicketstuff release for current wicket 1.4?
Stefan
-----Ursprüngliche Nachricht-----
Von: Major Péter [mailto:majorpetya@sch.bme.hu]
Gesendet: Dienstag, 23. März 2010 11:38
An: users@wicket.apache.org
Betreff: Re: Wicketstuff versioning
2010-03-23 11:24 keltezéssel, Boris Goldowsky írta:
> I may be wrong, but wouldn't it make sense to delay creating a 1.4.x
> branch until/unless someone actually wants to commit some code that
> would be different for 1.4.x and 1.5-SNAPSHOT? Once we branch, we have
> to start committing every bug fix to two different versions, right?
Yes, you're right about this, maybe we should wait until the first 1.5
RC with it.
> If we're lucky, everything in Wicketstuff may work fine unchanged with
> 1.4 and 1.5, and I suggest we can save ourselves a large amount of
> headache by just maintaining a single trunk, and bumping the version
> after there's an official Wicket release.
As far as I saw, there was some major modifications in the core around
the request-handling and URL-strategies, so this could rise up some issues.
> Of course, correct me if I'm wrong. I don't know how fundamentally
> different wicket 1.5 is going to be, or if there are a lot of people
> running snapshots of it now who would need Wicketstuff to be tracking
> it.
Is 1.5 RC1 good for everyone? :)
Regards,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Major Péter <ma...@sch.bme.hu>.
2010-03-23 11:24 keltezéssel, Boris Goldowsky írta:
> I may be wrong, but wouldn't it make sense to delay creating a 1.4.x
> branch until/unless someone actually wants to commit some code that
> would be different for 1.4.x and 1.5-SNAPSHOT? Once we branch, we have
> to start committing every bug fix to two different versions, right?
Yes, you're right about this, maybe we should wait until the first 1.5
RC with it.
> If we're lucky, everything in Wicketstuff may work fine unchanged with
> 1.4 and 1.5, and I suggest we can save ourselves a large amount of
> headache by just maintaining a single trunk, and bumping the version
> after there's an official Wicket release.
As far as I saw, there was some major modifications in the core around
the request-handling and URL-strategies, so this could rise up some issues.
> Of course, correct me if I'm wrong. I don't know how fundamentally
> different wicket 1.5 is going to be, or if there are a lot of people
> running snapshots of it now who would need Wicketstuff to be tracking
> it.
Is 1.5 RC1 good for everyone? :)
Regards,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Boris Goldowsky <bg...@cast.org>.
I may be wrong, but wouldn't it make sense to delay creating a 1.4.x
branch until/unless someone actually wants to commit some code that
would be different for 1.4.x and 1.5-SNAPSHOT? Once we branch, we have
to start committing every bug fix to two different versions, right?
If we're lucky, everything in Wicketstuff may work fine unchanged with
1.4 and 1.5, and I suggest we can save ourselves a large amount of
headache by just maintaining a single trunk, and bumping the version
after there's an official Wicket release.
Of course, correct me if I'm wrong. I don't know how fundamentally
different wicket 1.5 is going to be, or if there are a lot of people
running snapshots of it now who would need Wicketstuff to be tracking
it.
Bng
On Mon, 2010-03-22 at 19:07 +0100, Major Péter wrote:
> Yepp, nice chat, but who wants to do the dirty work??
> The first thing would be to create the 1.4.x branch, then release the
> current state as wicketstuff 1.4.7, and then modify the settings of the
> trunk to compile with wicket trunk.
> Let's split these jobs up to people, then do it.
> Also maybe we should write some policies about projects and maintaining
> the projects (like the current maintainers e-mail address should be
> available in the project pom.xml#developers tag, something like that),
> but this is an another thread...
>
> Best Regards,
> Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Major Péter <ma...@sch.bme.hu>.
Yepp, nice chat, but who wants to do the dirty work??
The first thing would be to create the 1.4.x branch, then release the
current state as wicketstuff 1.4.7, and then modify the settings of the
trunk to compile with wicket trunk.
Let's split these jobs up to people, then do it.
Also maybe we should write some policies about projects and maintaining
the projects (like the current maintainers e-mail address should be
available in the project pom.xml#developers tag, something like that),
but this is an another thread...
Best Regards,
Peter
2010-03-19 15:04 keltezéssel, Boris Goldowsky írta:
> nino martinez wael wrote:
>> I'll be happy to join in Boris.
>>
> That would be awesome, thanks Nino.
>
> I'm thinking the first thing would be to bump the wicket dependency to
> v1.4.7 and do a maven release of the current state of wicketstuff-core
> as version 1.4.7. Make sense? Is that something you could do?
>
> Stefan Lindner wrote:
>> Perhaps we should define an island of stability (like the name
>> wickststuff-core implies).
> I agree with that & the rest of your message. Jeremy put together a
> nice framework under wicketstuff-core, and there are a decent set of
> modules in there. How about calling those the stable set. Anyone can
> put something into core - as long as it works and they're willing to
> make some effort to keep it working. If one of the core modules breaks
> with a future wicket version, and no one steps up to fix it, then it
> gets dropped out of wicketstuff-core.
>
>> And: YES, I would help to maintain such a stable core of wicketstuff.
> Great!! I think with 4 or 5 people it shouldn't be a terrible task.
> (of course I could be wrong...)
>
> Bng
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Boris Goldowsky <bg...@cast.org>.
nino martinez wael wrote:
> I'll be happy to join in Boris.
>
That would be awesome, thanks Nino.
I'm thinking the first thing would be to bump the wicket dependency to
v1.4.7 and do a maven release of the current state of wicketstuff-core
as version 1.4.7. Make sense? Is that something you could do?
Stefan Lindner wrote:
> Perhaps we should define an island of stability (like the name wickststuff-core implies).
I agree with that & the rest of your message. Jeremy put together a
nice framework under wicketstuff-core, and there are a decent set of
modules in there. How about calling those the stable set. Anyone can
put something into core - as long as it works and they're willing to
make some effort to keep it working. If one of the core modules breaks
with a future wicket version, and no one steps up to fix it, then it
gets dropped out of wicketstuff-core.
> And: YES, I would help to maintain such a stable core of wicketstuff.
Great!! I think with 4 or 5 people it shouldn't be a terrible task.
(of course I could be wrong...)
Bng
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by nino martinez wael <ni...@gmail.com>.
I'll be happy to join in Boris.
2010/3/18 Boris Goldowsky <bg...@cast.org>
> Thank you for your thoughts Jeremy -- and your previous work on
> WicketStuff. I am certainly unhappy to hear that it felt like torture
> and that junk was being dumped on you rather than getting support from
> the community.
>
> I'd volunteer to put a bit of time into this, but I don't have time to
> be sole maintainer either. Maybe there could be a small group who all
> helped out - anyone else on this list willing to step up?
>
> I already offered to fix and update the TinyMCE module, but that is
> currently stalled since the necessary dependency is not in the
> repository and I don't have permissions to add it.
>
> Bng
>
>
> On Wed, 2010-03-17 at 16:21 -0500, Jeremy Thomerson wrote:
>
> >
> > I tried. I don't have the time it takes. With the free-for-all access
> that
> > is given to it, people consistently commit inconsistent junk that they
> don't
> > ever intend on maintaining in there. Feel free to take over - most of
> the
> > reorganization work is already done for you - by me. You can pick up
> where
> > I left off and carry the torture stake as far as you want.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicketstuff versioning
Posted by Boris Goldowsky <bg...@cast.org>.
Thank you for your thoughts Jeremy -- and your previous work on
WicketStuff. I am certainly unhappy to hear that it felt like torture
and that junk was being dumped on you rather than getting support from
the community.
I'd volunteer to put a bit of time into this, but I don't have time to
be sole maintainer either. Maybe there could be a small group who all
helped out - anyone else on this list willing to step up?
I already offered to fix and update the TinyMCE module, but that is
currently stalled since the necessary dependency is not in the
repository and I don't have permissions to add it.
Bng
On Wed, 2010-03-17 at 16:21 -0500, Jeremy Thomerson wrote:
>
> I tried. I don't have the time it takes. With the free-for-all access that
> is given to it, people consistently commit inconsistent junk that they don't
> ever intend on maintaining in there. Feel free to take over - most of the
> reorganization work is already done for you - by me. You can pick up where
> I left off and carry the torture stake as far as you want.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Jeremy Thomerson <je...@wickettraining.com>.
Comments inline....
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Mar 17, 2010 at 2:25 PM, Boris Goldowsky <bg...@cast.org>wrote:
> It sounds like whoever is responsible for wicketstuff needs to make a clear
> choice here.
>
The community is responsible for WicketStuff. This includes you.
> Is Wicketstuff going to be maintained as a place where lots of useful
> add-ons will live? If so, it needs someone to take a slightly more active
> role as curator; make sure the releases are done in parallel with wicket
> releases, make sure modules don't get dumped there without at least some
> documentation; and weed out modules that are abandoned, where no one
> volunteers to take on maintenance, or whose function has been absorbed into
> wicket's core.
>
I tried. I don't have the time it takes. With the free-for-all access that
is given to it, people consistently commit inconsistent junk that they don't
ever intend on maintaining in there. Feel free to take over - most of the
reorganization work is already done for you - by me. You can pick up where
I left off and carry the torture stake as far as you want.
Alternatively, make it clear that wicketstuff is NOT going to be maintained,
> and people like me who would like to share modules will share them in some
> other way - on Google code, a personal website, or whatever.
>
*Pieces* of WicketStuff will not be maintained. Unfortunately, that's the
way it's always been, and if you intend on releasing something that really
is going to be maintained, I'd definitely suggest using something else like
Google Code, GitHub, etc...
> Either way is ok I think, it just would be useful for those of us who are
> interested in contributing modules to know.
>
Search the list - you'll see many similar thoughts to this over the years
related to WicketStuff.
Thanks
> Bng
>
>
>
> Jeremy Thomerson wrote:
>
>> Really, it should match what's at trunk of Wicket, which should be
>> 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT.
>> But, nobody is really maintaining it any more, so it's a free-for-all.
>> That's always been the problem with WicketStuff.
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>> On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky <bgoldowsky@cast.org
>> >wrote:
>>
>>
>>
>>> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of SVN.
>>> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket?
>>>
>>> Bng
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicketstuff versioning
Posted by Boris Goldowsky <bg...@cast.org>.
It sounds like whoever is responsible for wicketstuff needs to make a
clear choice here.
Is Wicketstuff going to be maintained as a place where lots of useful
add-ons will live? If so, it needs someone to take a slightly more
active role as curator; make sure the releases are done in parallel with
wicket releases, make sure modules don't get dumped there without at
least some documentation; and weed out modules that are abandoned, where
no one volunteers to take on maintenance, or whose function has been
absorbed into wicket's core.
Alternatively, make it clear that wicketstuff is NOT going to be
maintained, and people like me who would like to share modules will
share them in some other way - on Google code, a personal website, or
whatever.
Either way is ok I think, it just would be useful for those of us who
are interested in contributing modules to know.
Thanks
Bng
Jeremy Thomerson wrote:
> Really, it should match what's at trunk of Wicket, which should be
> 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT.
> But, nobody is really maintaining it any more, so it's a free-for-all.
> That's always been the problem with WicketStuff.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
> On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky <bg...@cast.org>wrote:
>
>
>> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of SVN.
>> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket?
>>
>> Bng
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicketstuff versioning
Posted by Jeremy Thomerson <je...@wickettraining.com>.
Really, it should match what's at trunk of Wicket, which should be
1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT.
But, nobody is really maintaining it any more, so it's a free-for-all.
That's always been the problem with WicketStuff.
--
Jeremy Thomerson
http://www.wickettraining.com
On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky <bg...@cast.org>wrote:
> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of SVN.
> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket?
>
> Bng
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>