i'm also kindof 0/+1, which is why i didn't spend a huge amount of energy trying to do this.
i'd like to point out though that from a public relations point of view, we could hurt ourselves here too. if we demo stuff for people in the examples that turns out not to be ready for real world projects, they may feel disillusioned when they go to actually turn those examples into real world apps. the lure is that we show how wicket is going to sizzle in the future. the danger is that people get sold on something that isn't real yet. i'd rather have wicket do just a few things really well in 1.0 and then expand that in 1.1.
well, it's just one more thing for the beginning user to download and get confused by... i'd rather examples just depended on core and extensions.
Typically the examples distribution already includes the corresponding wicket-contrib. The users that get confused by having to download a dependency (that is fairly good documented in the project.xml) should get CVS_HEAD in the first place ;-)
It is a showcase afterall. It also depends on a ton of other libraries, so I don't see any problem in it depending on the contrib project.
If your opinion is that the dependency should move to the extensions project, the extensions project should be extended with the contrib components used in the examples project. (does that sentence make any sense?)
i'm not sure what you mean, but we only want stuff in extensions that's really polished. the contrib stuff used by the examples is not ready for prime time. that's another reason i'd rather contrib stuff wasn't in examples... as cool as they are, the contrib examples are like the contrib code... not really quite ready for some beginning user to discover.
So what you are really saying is that the wicket-examples project should only show admitted components either from wicket-core and wicket-extensions. All other showcasing stuff should be moved into contrib.
I share your sentiment on the quality aspect. However from a public relations view, I can also imagine this being the prime project to show *what* wicket can do for you. Limiting the project to examples of core and extension wickets seems rather drastic. This would only leave 'helloworld' (and some others).
i'm okay with leaving it as it is, but i'd love it if someone had the energy to move all the contrib-depending examples to
wicket-contrib/src/java/wicket/contrib/examples
I am +0/-1 for the change. I find the balance between 'conceptual integrity' and 'public relations' undecidable. We don't seem to gain much by splitting this up. If everybody shares the view that the wicket-contrib is actually a sandbox for wickets, then I'm +1 for the move as usecases of wickets should be developed next to the wicket. If we view the examples as a showcase for what Wicket can possibly do, *and* the contrib package has some kind of status above sandbox, I think we should leave it be...
Anyone else have an opinion?
Martijn
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
