Re: Wicketstuff versioning

2010-03-24 Thread nino martinez wael
 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 majorpe...@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-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-23 Thread Boris Goldowsky
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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-23 Thread Major Péter
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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



RE: Wicketstuff versioning

2010-03-23 Thread Stefan Lindner
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:majorpe...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-23 Thread nino martinez wael
+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 lind...@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:majorpe...@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-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-23 Thread Nicolai Guba
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 lind...@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:majorpe...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-23 Thread Major Péter
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 lind...@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:majorpe...@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-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-23 Thread nino martinez wael
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 majorpe...@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 lind...@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:majorpe...@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-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-23 Thread Michael O'Cleirigh

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étermajorpe...@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 Lindnerlind...@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:majorpe...@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

Re: Wicketstuff versioning

2010-03-23 Thread Boris Goldowsky
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étermajorpe...@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 Lindnerlind...@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:majorpe...@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

Re: Wicketstuff versioning

2010-03-23 Thread nino martinez wael
 with a smaller step and create a core wicketstuff
 release for current wicket 1.4?

 Stefan

 -Ursprüngliche Nachricht-
 Von: Major Péter [mailto:majorpe...@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-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-23 Thread Major Péter
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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-22 Thread Major Péter
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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-19 Thread nino martinez wael
I'll be happy to join in Boris.

2010/3/18 Boris Goldowsky bgoldow...@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-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




RE: Wicketstuff versioning

2010-03-19 Thread Stefan Lindner
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:mcgreg...@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 bgoldow...@cast.orgwrote:
 

  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-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
  
 

 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-19 Thread Boris Goldowsky

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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-19 Thread Major Péter
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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-19 Thread Jeremy Thomerson
2010/3/19 Major Péter majorpe...@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

2010-03-18 Thread Martin Grigorov
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 bgoldow...@cast.orgwrote:
 

  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-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
  
 

 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-18 Thread nino martinez wael
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 mcgreg...@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 bgoldow...@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-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
  
  
  
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 




 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Wicketstuff versioning

2010-03-18 Thread Boris Goldowsky
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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-17 Thread Jeremy Thomerson
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 bgoldow...@cast.orgwrote:

 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-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Wicketstuff versioning

2010-03-17 Thread Boris Goldowsky
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 bgoldow...@cast.orgwrote:

  

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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org





  


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-17 Thread Major Péter
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
 bgoldow...@cast.orgwrote:

  
 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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicketstuff versioning

2010-03-17 Thread Jeremy Thomerson
Comments inline

--
Jeremy Thomerson
http://www.wickettraining.com


On Wed, Mar 17, 2010 at 2:25 PM, Boris Goldowsky bgoldow...@cast.orgwrote:

 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 bgoldow...@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-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org








 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Wicketstuff versioning

2010-03-17 Thread Jeremy Thomerson
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 majorpe...@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
  bgoldow...@cast.orgwrote:
 
 
  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-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Wicketstuff versioning

2010-03-16 Thread Boris Goldowsky
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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org