i love the fact that wicketstuff is both a playground (very little entry
barrier for anyone) and that it serves as a repository for additional wicket
modules. the problem is when i look into trunk i see ten thousand projects.
some are dead, some are half dead, and others are alive. how am i supposed
to know what is what?
i think what we should do is create a two-tier system where projects that
are alive are directly in trunk, while other projects are in a subdirectory
of trunk. projects can move between these two tiers as needed.
what defines a project as alive? at the least it works, not just compiles.
take data-hibernate 3. it compiles, but doesnt work because it hasnt been
synced with hibernate 3 changes. if someone was to pick it up, fix it so it
works, etc, then it can be moved into trunk again.
or something like that.
-igor
On 5/6/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
On 5/6/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
> As a wicket-stuff developer, I for one would hate to see restrictions
> placed on what can or can not be a wicket-stuff project.
This was not a thread on what constitutes a wicket stuff project, but
now that you brought it up :)
In my vision, there is no restriction (bar the things sf.net policies
and good taste prohibit) on what can be a Wicket Stuff project.
> The beauty
> of the wicket-stuff idea is that it is a playground for people try out
> potentially cool ideas. It's a place for people to learn how to use
> wicket and build "possibly" cool widgets and tools.
Yes, but we should be able to keep it clean/real, in that the SVN
trunk does not end up as a dumping ground for dead projects and broken
ideas.
I would like the projects to be maintained (not as vigorously as
wicket core is, but at least migrate with each release of Wicket, and
get a download from either the maven repository or the sf.net download
area).
As such, I think the minimal requirements for a Wicket contrib project
would be:
- a page in the wicketstuff wiki explaining:
* what the project does
* who is maintaining it
* the intent of the project (example, actual usage, experiment, ?)
- if the intent is actual usage: a release with at least each major
wicket release
- if the intent is example or experiment: description on how to get
it and start with it
I am in doubt on what to do with projects that don't get maintained:
- letting them sit -> gives a bad experience for users trying the
projects out (see maven), but allows new users to pick up the code and
do something with it
- removing them/moving to attic -> makes the projects invisible and
virtually annihilates the opportunity of someone else picking the
project up
If a project that has been in limbo for a while has a viable
alternative, I would opt to remove the dead project. If there is no
alternative, I would opt to keep it.
> I know that *my* project (wicketstuff-scriptaculous) has occasionally
> been left "in the dark" for several months before a whole slew of
> changes and features get built in.
The scriptaculous project is actively maintained in my book: regular
code additions, blog entries, etc. and would be an example for other
projects. Thanks for that!
> Sure, there may be a "better" wicket/hibernate project out there (aka:
> databinder), but I really don't see any issues with that. Especially
> now that there's a wicket-stuff wiki, it can be clearly spelled out
> there what each project's strengths/weaknesses are.
But that was not even available for these projects. That prompted me
to ask if these are actively maintained and what we should do with
them. *Only* if they were not maintained I would want them be removed.
In this particular case, I would now only opt for removing the
distributables from the sf.net download site since these artifacts
don't have any value at the moment other than confusing new users.
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org
