Re: Wicket libraries
Hi, May be, a solution for your case would be to use ivy ant tasks to manage/list the dependencies of wicket. I don't use Ivy, but it could use maven's repositories and pom.xml. I'm not sur it help you, because I don't use it, like lot of, I like maven 2 (dependencies and conventions), and more when I switch to a ant project where I need to read it to understand where are things, what are there scope (test, compile,...) finding the right jars when I try Seam one year ago was a headhache... but it's off topic. /david Robo wrote: Hello, Ok, seems removing \wicket-velocity-1.3.0-beta3.jar\ from build path solved problem with velocity problem. But please explain me why removing package from build path solves the problem if nowhere in my Hello World code i call for any of the velocity packages. Is there some duplicities in packages or what? As to Maven2. It seems that like you in some way force developers to Maven2. :-) In wicket inAction EA there is just mentioned that when using Ant you need to do some work about libraries ant Maven manages it for you. This is too little for serious docs. Please do look into Icefaces free docs. There is steb by step mentioned what libs one need to enable which feature and the libs are added as demo app more feature ritch. Developer needs to understand core functionalities and dependencies. Just After understandig this developer is able to set up Ant project, make project, Eclipse or Netbeans based project and if you want also Maven. :-) But many of the advices about libs was \Use Maven2\ like. If you use it, so use it but do not force me to use it. Explain in some part od book or docs what do I need to run which part of wicket to save my time to go into jars and solve dependencies troubles. Yes Maven solves you some problems with dependecies and also si suitable for small pr oject but at big projects it definitely fails. :-/ So please. I know you have lot of work with wicket, and as users can see you have a good aproach. But please do spend some time to at least write one chapter about libraries, neede dependencies and so on. If you have licensing problems just make one clear site with core libs link, dep libs link and explanation what feature they are enabling and so on. And make some quick start page in which you explainn dependecies on simple sample app :-)Do not take alibistic aproach of hiding everithing besides Maven. :-) Off topic section: We use Maven for more than one year, also Maven2, in the begining there was some WoW`s about how Maven Manages project. Really great. But as the project continued and wee needed to add many not so standard feature to project, like advanced autorization, very non standard libraries we were forced in the troubles wchich could be avoided when there was no Maven2. also the project layout is not the best for our taste. IMHO of cource. Rewriting project build to ANT took us 6 days, but from that time we saved us a lot of time and nerves of solving Maven troubles. From that time we just developed, exactly what we were paid for. Idea of Maven2 is very nice and usefull, but implementation is kind of tragedy :-/. If I would Alayster Crowley I`d like Maven. Because its black magic, but I`m just dump developer who is not even to able to hypnotize someone :-)). as we talked about Ant and Maven2 we really realized the good sides of Maven. but Ant has simple basic idea with few bilding bl oc ks, which when you combine them wiselly works perfectly. YOU do no need to study Ant. Just use it. In Maven wee need to study Maven, Study black Magic without success. :-) It remainds me of one Joke. Americans was looking for some pen, which could be used in space without troubles, They invested 1 000 000 $ in research and finally had one. Russians in the meantime used pencils. :-) (If you do not like Russians just switch the roles ;-) ) So we found Maven2 usefull with small to mid project with some commonly used libraries but here it stops. Once you set up good dependencies in Ant you well understand what library you use and why (maven shields you from this in some way) and yuo are able to solve troubles with build system fast. We do not really to care about looking for jars in google. Using Maven it is not that time saving. It is more confortable I agree, but not worth the time to solve Maven troubles. There is lot of buzz about \Convention over configuration\, But if that convention is badly designed, like Maven project layout, our aproach is flexibility over convention. (Jsp is convention but then came grrat wicket wchich is typical flexibility over convention, or good convention over bad convention :-) ). But reality besides Rails and Wicket I did not see any good convention (over configuration). EnD of off topic: Uff ;-) Robert - Originálna Správa - Od: Jonathan Locke Komu: Poslaná: 06.09.2007 04:07 Predmet: Re: Wicket libraries not only would the download be bigger
Re: Re: Wicket libraries stack trace
\; Wicket Examples HelloWorldApplication org.apache.wicket.protocol.http.WicketFilter applicationClassName wicket.examples.helloworld.HelloWorldApplication HelloWorldApplication /app/* --- So please explain me why Tomcat is complaining at deployment time about velocity just including it in the build path? Regards Robo. - Originálna Správa - Od: Gwyn Evans Komu: Robo Poslaná: 06.09.2007 10:34 Predmet: Re: Wicket libraries On Thursday, September 6, 2007, 5:57:53 AM, Robo wrote: Ok, seems removing \\\wicket-velocity-1.3.0-beta3.jar\\\ from build path solved problem with velocity problem. But please explain me why removing package from build path solves the problem if nowhere in my Hello World code i call for any of the velocity packages. Is there some duplicities in packages or what? Well, without seeing your code or the full stacktrace, we can\'t be sure. There\'s always a chance that you\'ve left a that uses Velocity in the web.xml, for instance. As to Maven2. It seems that like you in some way force developers to Maven2. :-) In one sense, we do. If users who have problems are able to provide examples of their issues as QuickStart apps, then we\'re able to investigate and fix a lot easier. By using Maven and sticking to the standard project layout, we provide a layout familiar to a significant number of Java developers, thus minimising obstacles to getting them going. In wicket inAction EA there is just mentioned that when using Ant you need to do some work about libraries ant Maven manages it for you. This is too little for serious docs. Please do look into Icefaces free docs. There is steb by step mentioned what libs one need to enable which feature and the libs are added as demo app more feature ritch. Developer needs to understand core functionalities and dependencies. Just After understandig this developer is able to set up Ant project, make project, Eclipse or Netbeans based project and if you want also Maven. :-) But many of the advices about libs was \\\Use Maven2\\\ like. If you use it, so use it but do not force me to use it. We don\'t force you to use it, but if you do choose to swim upstream, you must expect to have to put in some extra work yourself. The information\'s there in easily accessible form and most users seem to manage find use it, even those who wish to use build systems other than Maven. The main issue that would occur with having a separate document detailing dependances is that it needs keeping in sync, which is why the one that I know of (and has been referenced recently) is one generated from the Maven build files. Frankly, any Java developer worth the name should be at least aware of how to read Maven pom.xml files in order to determine things such as dependances, in the same way that in the past, a basic familiarity with Makefiles and build.xml files would have been expected. Explain in some part od book or docs what do I need to run which part of wicket to save my time to go into jars and solve dependencies troubles. Yes Maven solves you some problems with dependecies and also si suitable for small pr oject but at big projects it definitely fails. :-/ Does the phrase \When in a hole, stop digging\ mean anything to you? While \'big\' is subjective, there are many projects that I\'d consider \'big\' that are quite happily using Maven - maybe the problem\'s not with the tool? So please. I know you have lot of work with wicket, and as users can see you have a good aproach. But please do spend some time to at least write one chapter about libraries, neede dependencies and so on. If you have licensing problems just make one clear site with core libs link, dep libs link and explanation what feature they are enabling and so on. The point is, this is all documented in the pom.xml, where you can be sure that it\'s up-to-date correct, as else the builds would fail - if extracted into a document, you\'d never be 100% sure it wasn\'t out-of-date... And make some quick start page in which you explainn dependecies on simple sample app :-) $ mvn archetype:create -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.3.0-beta3 -DgroupId=com.mycompany -DartifactId=myproject $ cd myproject $ more pom.xml one Joke. Americans was looking for some pen, which could be used in space without troubles, They invested 1 000 000 $ in research and finally had one. Russians in the meantime used pencils. :-) Yes, that one\'s false too - http://www.snopes.com/business/genius/spacepen.asp. Lead pencils were used on all Mercury and Gemini space flights and all Russian space flights prior to 1968. Fisher Space Pens are more dependable than lead pencils and cannot create the hazard of a broken piece of lead floating
Re: Wicket libraries stack trace
On Thursday, September 6, 2007, 9:52:46 AM, Robo [EMAIL PROTECTED] wrote: So after I put wicket-velocity jar in my build path, I`m getting following errors. (I`m using nothing from it and the prove is when I remove it it deploys OK.) ... So please explain me why Tomcat is complaining at deployment time about velocity just including it in the build path? What's happening is that the Wicket Application instance has searched the classpath to read all the wicket.properties files provided. The one in the wicket-velocity jar says initializer=org.apache.wicket.velocity.Initializer, so it's trying to run that initializer instance, but you're missing the dependances. If using Maven, you'd have them, but if not, you can go to MvnRepository (http://mvnrepository.com/) and search which would take you to http://mvnrepository.com/artifact/velocity/velocity/1.4 where it shows that you need velocity-dep-1.4.jar too. That's a useful site to bookmark, whether using Maven or not (probably even more if not!) /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
Robo wrote: Ok, seems removing \wicket-velocity-1.3.0-beta3.jar\ from build path solved problem with velocity problem. But please explain me why removing package from build path solves the problem if nowhere in my Hello World code i call for any of the velocity packages. Is there some duplicities in packages or what? I expect because Wicket looks on the classpath for Wicket modules to initialise, finds some in that JAR, tries to and then can't find one of its dependencies. Modern Java apps tend to be complex beasts, with lots of dependencies. If you insist on managing these manually, you can expect to have a fair bit of work to do. That's why things like Ivy and Maven 2 were invented. As to Maven2. It seems that like you in some way force developers to Maven2. :-) No, not at all. But if you've deliberately chosen to manage your dependencies manually when there are perfectly good ways of doing it automatically, then we're not going to hold your hand for you. We don't get paid to do this, you know. If you don't like Maven 2 no one is forcing you to use it. Use Ivy instead. Or use the standalone Maven 2 Ant tasks for doing dependencies. Alternatively, install Maven 2, use it to build a quickstart WAR file with all the things you need, and then grab the JARs from there. Any of these options would take you a tenth of the time you've spent bitching on this mailing list. Yes Maven solves you some problems with dependecies and also si suitable for small project but at big projects it definitely fails. :-/ So Geronimo is a small project? And Jetty? And Apache Directory Server? And Wicket for that matter? And the several-hundreds-of-thousands-of- lines, 200+ dependencies projects we have here that use it? Jeez - I may have a high horse, but yours is scraping the stratosphere. Sure, it has some issues, but so does anything complex. The simple point is that for most people, Ivy or Maven 2 do what they want it to do. If you don't like any of these automated tools and insist on doing it all manually, you can't expect us to have all that much time for you, as we don't get paid to do this, you know. It's like you're complaining that there's no documentation on how to hammer in a nail using a screwdriver. So please. I know you have lot of work with wicket, and as users can see you have a good aproach. But please do spend some time to at least write one chapter about libraries, neede dependencies and so on. If you have licensing problems just make one clear site with core libs link, dep libs link and explanation what feature they are enabling and so on. And make some quick start page in which you explainn dependecies on simple sample app :-)Do not take alibistic aproach of hiding everithing besides Maven. :-) Why don't you write a wiki page for us? Despite the fact I'm not being paid to be your tech support, I've taken some time out to give you a text file exhaustively detailing the required dependencies for each of our modules, including the transitive ones. I have done the work for you (not that you've even murmured a thank you), so why are you still bitching about it? Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Wicket libraries stack trace
On 06 Sep 2007 11:44:56 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: Ok Thnaks for explanation. And do not look for truth in jokes. Jokes are just jokes ;-) But you are not using Velocity panel right? Why do you include that jar in the first place? You can just include the core wicket jar. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Wicket libraries stack trace
And why not? Besides that Wicket is doing some initialization of not used libraries is there any restriction of not including not neccesary libraries in classpath? Most time I develop someting I have many libraries in my classpath even if I do not use them ... Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 18:09 Predmet: Re: Re: Wicket libraries stack trace On 06 Sep 2007 11:44:56 +0200 (CEST), Robo wrote: Ok Thnaks for explanation. And do not look for truth in jokes. Jokes are just jokes ;-) But you are not using Velocity panel right? Why do you include that jar in the first place? You can just include the core wicket jar. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mozaika storočia denníka SME - http://mozaika.sme.sk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Wicket libraries stack trace
On 06 Sep 2007 17:23:13 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: And why not? Besides that Wicket is doing some initialization of not used libraries is there any restriction of not including not neccesary libraries in classpath? Most time I develop someting I have many libraries in my classpath even if I do not use them ... Because you seem to be running into trouble with your dependencies. If you include wicket-velocity, you need Velocity (which you could have guessed from the name of the project) and any dependencies Velocity has. If don't include wicket-velocity, you don't need Velocity. It's that simple. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Wicket libraries
Java jars are nto at all complex beast. They become tricky in situation where you just put some of them inclasspath and they do what you normally do not expect. Lib should be lib and when not called by developer they should do nothing. Deliberatly breaking this rule makes the jars, beast ... :-) Sorry, but that is b.s. Could you point me where this 'rule' is defined? You bet you can have troubles if you just mindlessly include all kinds of jars. Furthermore, what is your whole point of having to include jars you are not using? If you would be using them, you'd need those other dependencies, period. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Wicket libraries stack trace
After small troubles I had with it I know it. But from my point of view it is not correct to initiatie not used libraries just by including it in App Server classpath. From my point of view lib is lib, and when nto called by developer it sould not be initiated by App server. I runned into troubles with dependecies SELF initialized itself. I saw this behaviur several times before but everytime I`m suprised. As I said from my point of view, lib is lib. But this guides me to troubles :-) But to be concrete I need to develop demo app using fove frameworks, not using Maven :-), so I put every lib in wicket into lib dir to not to solve missing lib troubles when building demo app. But it raised contrary, unnessesary \self living\ lib problem. So Eelco we could probably close this thread as my troubles with Hello World are solved, now begins the trouble with demo app. So thanks for help and good product. Demo app will be presented week after next week so we`ll see hov wicket compares to other frameworks. Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 18:17 Predmet: Re: Re: Re: Wicket libraries stack trace On 06 Sep 2007 17:23:13 +0200 (CEST), Robo wrote: And why not? Besides that Wicket is doing some initialization of not used libraries is there any restriction of not including not neccesary libraries in classpath? Most time I develop someting I have many libraries in my classpath even if I do not use them ... Because you seem to be running into trouble with your dependencies. If you include wicket-velocity, you need Velocity (which you could have guessed from the name of the project) and any dependencies Velocity has. If don\'t include wicket-velocity, you don\'t need Velocity. It\'s that simple. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Sprievodca herným svetom - http://hry.sme.sk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Wicket libraries stack trace
On 06 Sep 2007 18:11:09 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: After small troubles I had with it I know it. But from my point of view it is not correct to initiatie not used libraries just by including it in App Server classpath. From my point of view lib is lib, and when nto called by developer it sould not be initiated by App server. I runned into troubles with dependecies SELF initialized itself. I saw this behaviur several times before but everytime I`m suprised. As I said from my point of view, lib is lib. But this guides me to troubles :-) But to be concrete I need to develop demo app using fove frameworks, not using Maven :-), so I put every lib in wicket into lib dir to not to solve missing lib troubles when building demo app. But it raised contrary, unnessesary \self living\ lib problem. You can't really depend on libs following such rules. All sorts of frameworks do this, from Guice to Seam to logging libraries, and it can get you in trouble with XML handling as well. As a general rule, only include what you need. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Wicket libraries
Sorry Eelco but me and also quite a lot of other developers(I know, contrary to others developers) consider same b.s. libraries which are \alive\ just because they are in classpath. It is like talking when nobody asks you ... Look at Java SDK do you need all packages to build console \Hello World!\ No. And who cares. They are just there and do their stuff when needed. So why wicket-velocity is doing job developer do not want and did not asked to. Where is writen that I cannot put mindesly tens of useles libs when they just sit there, assuming of course the packages are not duplicating. Do you understand why there are packages Eelco. Unles the class is uniqeu develioper should not be afreaid of using other class he wanted. To push your false premise to edge, why you deliberatly put all packages and classes into jar when you need just few of them also with dependencies. Isn`t it b.s.? Yes it is .. and also it is not conceptual ... Do not make zombie libraries and there will be no problem with dependecies. Got the point? If not I`m not alble not help you sorry ... Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 18:59 Predmet: Re: Re: Wicket libraries Java jars are nto at all complex beast. They become tricky in situation where you just put some of them inclasspath and they do what you normally do not expect. Lib should be lib and when not called by developer they should do nothing. Deliberatly breaking this rule makes the jars, beast ... :-) Sorry, but that is b.s. Could you point me where this \'rule\' is defined? You bet you can have troubles if you just mindlessly include all kinds of jars. Furthermore, what is your whole point of having to include jars you are not using? If you would be using them, you\'d need those other dependencies, period. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Najoriginalnejsie technologicke hracky - http://pocitace.sme.sk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Wicket libraries stack trace
Yes I know Eelco. That is why there are so much troubles in Java programming land. Misusing of basic concepts ... That is why one needs some sort of COC, because there is lot`s of b.s. around ... J2EE 1.4 countained so much of it that lots of developers refused to use it And it had to be rewriten ... Apache Struts ... JSF ... Why did you started Wicket? Did`nt you wrote that MVC is kind of missconceptin? And I ask you Who told that? Eelco Hilenius? Yes and you were probably right. And in that time you with the tapestry was alone against the JSF Struts community. So accpet pleace that someone else is seeing miisconceptions and b.s. in other aspetcs of java programming and habits. OK? :-) Can we finish? As you can see I do not share view of major java programmers but accepting the situation ... :-)) Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 19:08 Predmet: Re: Re: Re: Re: Wicket libraries stack trace On 06 Sep 2007 18:11:09 +0200 (CEST), Robo wrote: After small troubles I had with it I know it. But from my point of view it is not correct to initiatie not used libraries just by including it in App Server classpath. From my point of view lib is lib, and when nto called by developer it sould not be initiated by App server. I runned into troubles with dependecies SELF initialized itself. I saw this behaviur several times before but everytime I`m suprised. As I said from my point of view, lib is lib. But this guides me to troubles :-) But to be concrete I need to develop demo app using fove frameworks, not using Maven :-), so I put every lib in wicket into lib dir to not to solve missing lib troubles when building demo app. But it raised contrary, unnessesary \\\self living\\\ lib problem. You can\'t really depend on libs following such rules. All sorts of frameworks do this, from Guice to Seam to logging libraries, and it can get you in trouble with XML handling as well. As a general rule, only include what you need. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mozaika storočia denníka SME - http://mozaika.sme.sk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
You can use Ivy to resolve wicket dependencies and produce a report, if you have trouble to generate a report with maven ATM. The report details may be slightly different from what you get with m2, since Ivy is not 100% compatible with m2, but it's better than nothing. If you're interested, I can provide the build.xml to generate it (with automatic download of Ivy so that you only need ant 1.6+ on your box to test it). Would you be interested as a workaround until you get maven 2 site generation working? Xavier On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Skinning was not a problem, just generating a coherent site with just one command: cd wicket-1.x mvn site:deploy This just doesn't work (tm). Martijn On 9/5/07, Igor Vaynberg [EMAIL PROTECTED] wrote: we dont need links, just a list. and i thought the trouble was related to skinning? if thats still the case can we just put a vanilla maven site on wicket-stuff or somewhere? -igor On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Remember the troubles I had with generating the site? Tim was working on it, but it still is a long shot from being workable. And yes, it has a list of dependencies, but I don't think they generate a link to download each and every one of them :| Martijn On 9/5/07, Igor Vaynberg [EMAIL PROTECTED] wrote: why dont we generate the maven stie somewhere? doesnt that have a list of dependencies for each module? -igor On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: On 9/5/07, Al Maw [EMAIL PROTECTED] wrote: That said, maybe we should provide a separate ZIP with the dependencies. I guess if you're using Ivy or Maven 2, you're not going to be downloading the ZIP at all. There may be licensing issues with this, though. What do people think? Martijn? Including the deps just doesn't increase the size to a double, but a 5 or 6 fold (iirc 65MB). The problem is with transitive deps that are test/compile/provided scope (for instance Spring includes just about the world). The best way currently is to do it as we do now IMO. The current direct deps are license compatible, but I really don't want to check all transitive deps for license compatibility. The current examples is already quite humongous in the dependency department. I have proposed a couple of weeks ago to move examples out of the main distribution, and make it a separate download, and do the same with the quickstart. The benefit would be that the license requirements for the main distribution download becomes smaller, only the stuff we include in the sources ourselves. Both the examples and quickstart would then include all necessary runtime deps for building a wicket application (as described in chapter 3 of wicket in action, and provided with wicket 1.2 until now). This makes them easier to provide a license file for. I just lack the time to make it so. In short: I don't like the idea of adding an all libs project and make it downloadable from Apache. We could make that a wicket stuff project though but the size would resemble downloading a whole maven repository. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://incubator.apache.org/ivy/ http://www.xoocode.org/
Re: Re: Wicket libraries
On 06 Sep 2007 17:35:26 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: Stop it now please Al. You take oo personal aproach. Nobody forced you in responding. heh, what you have to understand is that wicket is oss - so it IS personal. it is something we work on in our spare time so it is kind of a hobby (a demanding hobby). we do care about it a great deal. constructive criticism is always welcome, but you have to have a level of respect on the lists. You make Wicket And I`m the user. If you do not like it do not do it. But there is some responsibilities about product you develop towards product users so do not confuse roles please. wrong again. its the other way around. if you do not like it do not use it. we do not owe you anything. we put wicket out there for people to use, no strings attached. And besides that I`m also kind of customer As I paid for the book ;-) you paid for the book, but we get nothing from that. so how do you connect the dots? And besides that I several times said how Wicket is great is that not enaugh for you? :-)) thank you. And btw I thanked to Gvyn at the end of my troubles as his responcese solved them. I do not thank before my troubles gets solved ;-) I`m not teacher in the dance school. its not the missing thank you, it is more your superior attitute and your lecturing tone. so in fact you do come across as a teacher. What I`m doing now is preparing presentation to my chiefs and currrently I`m coping with five frameworks amking demo apps and have two weeks for it. That is Why I`m not writing wiki and that is why I`m sometimes upset about lack of docs, working 18-20 hours per day ... sounds like your chiefs are pretty dumb if they expect you to learn five frameworks in two weeks, find a better job. as for the issue at hand, i believe the velocity initializer should be rewritten to check if whatever it needs is actually on the classpath, and noop quietly if its not. please file a jira issue. -igor Java jars are nto at all complex beast. They become tricky in situation where you just put some of them inclasspath and they do what you normally do not expect. Lib should be lib and when not called by developer they should do nothing. Deliberatly breaking this rule makes the jars, beast ... :-) So Finishing this personal thread and thank you for much of your time ;-)) Robo - Originálna Správa - Od: Al Maw Komu: Poslaná: 06.09.2007 17:44 Predmet: Re: Wicket libraries Robo wrote: Ok, seems removing \\\wicket-velocity-1.3.0-beta3.jar\\\ from build path solved problem with velocity problem. But please explain me why removing package from build path solves the problem if nowhere in my Hello World code i call for any of the velocity packages. Is there some duplicities in packages or what? I expect because Wicket looks on the classpath for Wicket modules to initialise, finds some in that JAR, tries to and then can\'t find one of its dependencies. Modern Java apps tend to be complex beasts, with lots of dependencies. If you insist on managing these manually, you can expect to have a fair bit of work to do. That\'s why things like Ivy and Maven 2 were invented. As to Maven2. It seems that like you in some way force developers to Maven2. :-) No, not at all. But if you\'ve deliberately chosen to manage your dependencies manually when there are perfectly good ways of doing it automatically, then we\'re not going to hold your hand for you. We don\'t get paid to do this, you know. If you don\'t like Maven 2 no one is forcing you to use it. Use Ivy instead. Or use the standalone Maven 2 Ant tasks for doing dependencies. Alternatively, install Maven 2, use it to build a quickstart WAR file with all the things you need, and then grab the JARs from there. Any of these options would take you a tenth of the time you\'ve spent bitching on this mailing list. Yes Maven solves you some problems with dependecies and also si suitable for small project but at big projects it definitely fails. :-/ So Geronimo is a small project? And Jetty? And Apache Directory Server? And Wicket for that matter? And the several-hundreds-of-thousands-of- lines, 200+ dependencies projects we have here that use it? Jeez - I may have a high horse, but yours is scraping the stratosphere. Sure, it has some issues, but so does anything complex. The simple point is that for most people, Ivy or Maven 2 do what they want it to do. If you don\'t like any of these automated tools and insist on doing it all manually, you can\'t expect us to have all that much time for you, as we don\'t get paid to do this, you know. It\'s like you\'re complaining that there\'s no documentation on how to hammer in a nail using a screwdriver. So please. I know you have lot of work with wicket, and as users can see you have a good aproach. But please do spend some time to at least write one
Re: Re: Re: Wicket libraries
On 06 Sep 2007 18:24:44 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: Sorry Eelco but me and also quite a lot of other developers(I know, contrary to others developers) consider same b.s. libraries which are \alive\ just because they are in classpath. It is like talking when nobody asks you ... Look at Java SDK do you need all packages to build console \Hello World!\ No. And who cares. They are just there and do their stuff when needed. So why wicket-velocity is doing job developer do not want and did not asked to. Where is writen that I cannot put mindesly tens of useles libs when they just sit there, assuming of course the packages are not duplicating. Do you understand why there are packages Eelco. Unles the class is uniqeu develioper should not be afreaid of using other class he wanted. To push your false premise to edge, why you deliberatly put all packages and classes into jar when you need just few of them also with dependencies. Isn`t it b.s.? Yes it is .. and also it is not conceptual ... Do not make zombie libraries and there wi ll be no problem with dependecies. Got the point? If not I`m not alble not help you sorry ... Yeah, it's not that I don't get your point, it's just that I don't agree. What I'm saying is that you don't live in that perfect world and not all software acts like you seem to expect. There is no rule that you can't what we do, and Java makes it possible. AND many other frameworks do this kind of initialization as well, so you can have the same problem in many other occasions. Not to mention problems with versioning and shared server libs you might have (especially with older app server versions) if you just include every jar you come across. Anyway, to my knowledge, wicket-velocity is the only project that initializes pulling in more dependencies. And as you're not using that, we can end this discussion now. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Wicket libraries stack trace
On 06 Sep 2007 18:32:44 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: Yes I know Eelco. That is why there are so much troubles in Java programming land. Misusing of basic concepts ... That is why one needs some sort of COC, because there is lot`s of b.s. around ... J2EE 1.4 countained so much of it that lots of developers refused to use it And it had to be rewriten ... Apache Struts ... JSF ... Why did you started Wicket? Did`nt you wrote that MVC is kind of missconceptin? And I ask you Who told that? Eelco Hilenius? Yes and you were probably right. And in that time you with the tapestry was alone against the JSF Struts community. So accpet pleace that someone else is seeing miisconceptions and b.s. in other aspetcs of java programming and habits. OK? :-) Sure. You know, if you would just try to have a little bit more of a constructive tone... I'm sure we can patch wicket-velocity so that it avoids pulling in Velocity too early. And maybe the project tries to do too much upfront. Should be pretty easy to fix if you want to create a JIRA issue for it. About calling initializers (that's what triggers Velocity loading in this case), the feature is generally nice. We can use it to e.g. automatically register shared resources or like wicket-jmx does, register resources, so that to enable functionality in that lib is as easy as dropping in a jar. That's pretty cool functionality in my book. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Wicket libraries stack trace
Sorry Eelco but I did not start this small personal war. In my previus of topic marked post I said lot of good about wicket and made lot of PLEASE do this ... I know you have lot of work ... IMHO ... and so on ... Also thanked to Gwyn? ... :-))) Al getted touched about my troubles with Maven, you started to talking b.s. and mindless way of something and started to solve and the same time started to solve some morality questions and so on. Gwyn started to look for truth in Joke :-)) POint me in one of my post when I said about Maven, or your work, that it is b.s. or mindless something. ... YOu will not find it. And also any personal negative sentences towards to any of the developers. I`m not trying to be polite. I`m rying to be correct to people. At the same time you are too polite and agresive ... :-) So after more than 26 hours of programming and mailing I`ll go for a Little bit of sleep. :-)) Bye Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 19:54 Predmet: Re: Re: Re: Re: Re: Wicket libraries stack trace On 06 Sep 2007 18:32:44 +0200 (CEST), Robo wrote: Yes I know Eelco. That is why there are so much troubles in Java programming land. Misusing of basic concepts ... That is why one needs some sort of COC, because there is lot`s of b.s. around ... J2EE 1.4 countained so much of it that lots of developers refused to use it And it had to be rewriten ... Apache Struts ... JSF ... Why did you started Wicket? Did`nt you wrote that MVC is kind of missconceptin? And I ask you Who told that? Eelco Hilenius? Yes and you were probably right. And in that time you with the tapestry was alone against the JSF Struts community. So accpet pleace that someone else is seeing miisconceptions and b.s. in other aspetcs of java programming and habits. OK? :-) Sure. You know, if you would just try to have a little bit more of a constructive tone... I\'m sure we can patch wicket-velocity so that it avoids pulling in Velocity too early. And maybe the project tries to do too much upfront. Should be pretty easy to fix if you want to create a JIRA issue for it. About calling initializers (that\'s what triggers Velocity loading in this case), the feature is generally nice. We can use it to e.g. automatically register shared resources or like wicket-jmx does, register resources, so that to enable functionality in that lib is as easy as dropping in a jar. That\'s pretty cool functionality in my book. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Najpopulárnejší blog na Slovensku - http://blog.sme.sk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Wicket libraries
If you care about the product of your own work, it 's personal. O.S.S. is based on self motivated developers who, by definition, care about their work. On 06 Sep 2007 19:36:36 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: No Igor. Software is never personal. war is personal, dying of my mother, father and youg brother bombed by army aircraft is personal but software sure not ;-) If you can point me please to ANY of the disrespect sentences, except AL`s \why are you still bitching about it\ please do it ... :-) Robo - Originálna Správa - Od: \Igor Vaynberg\ Komu: Poslaná: 06.09.2007 19:36 Predmet: Re: Re: Wicket libraries On 06 Sep 2007 17:35:26 +0200 (CEST), Robo wrote: Stop it now please Al. You take oo personal aproach. Nobody forced you in responding. heh, what you have to understand is that wicket is oss - so it IS personal. it is something we work on in our spare time so it is kind of a hobby (a demanding hobby). we do care about it a great deal. constructive criticism is always welcome, but you have to have a level of respect on the lists. You make Wicket And I`m the user. If you do not like it do not do it. But there is some responsibilities about product you develop towards product users so do not confuse roles please. wrong again. its the other way around. if you do not like it do not use it. we do not owe you anything. we put wicket out there for people to use, no strings attached. And besides that I`m also kind of customer As I paid for the book ;-) you paid for the book, but we get nothing from that. so how do you connect the dots? And besides that I several times said how Wicket is great is that not enaugh for you? :-)) thank you. And btw I thanked to Gvyn at the end of my troubles as his responcese solved them. I do not thank before my troubles gets solved ;-) I`m not teacher in the dance school. its not the missing thank you, it is more your superior attitute and your lecturing tone. so in fact you do come across as a teacher. What I`m doing now is preparing presentation to my chiefs and currrently I`m coping with five frameworks amking demo apps and have two weeks for it. That is Why I`m not writing wiki and that is why I`m sometimes upset about lack of docs, working 18-20 hours per day ... sounds like your chiefs are pretty dumb if they expect you to learn five frameworks in two weeks, find a better job. as for the issue at hand, i believe the velocity initializer should be rewritten to check if whatever it needs is actually on the classpath, and noop quietly if its not. please file a jira issue. -igor Java jars are nto at all complex beast. They become tricky in situation where you just put some of them inclasspath and they do what you normally do not expect. Lib should be lib and when not called by developer they should do nothing. Deliberatly breaking this rule makes the jars, beast ... :-) So Finishing this personal thread and thank you for much of your time ;-)) Robo - Originálna Správa - Od: Al Maw Komu: Poslaná: 06.09.2007 17:44 Predmet: Re: Wicket libraries Robo wrote: Ok, seems removing \\\wicket-velocity-1.3.0-beta3.jar\\\ from build path solved problem with velocity problem. But please explain me why removing package from build path solves the problem if nowhere in my Hello World code i call for any of the velocity packages. Is there some duplicities in packages or what? I expect because Wicket looks on the classpath for Wicket modules to initialise, finds some in that JAR, tries to and then can\\\'t find one of its dependencies. Modern Java apps tend to be complex beasts, with lots of dependencies. If you insist on managing these manually, you can expect to have a fair bit of work to do. That\\\'s why things like Ivy and Maven 2 were invented. As to Maven2. It seems that like you in some way force developers to Maven2. :-) No, not at all. But if you\\\'ve deliberately chosen to manage your dependencies manually when there are perfectly good ways of doing it automatically, then we\\\'re not going to hold your hand for you. We don\\\'t get paid to do this, you know. If you don\\\'t like Maven 2 no one is forcing you to use it. Use Ivy instead. Or use the standalone Maven 2 Ant tasks for doing dependencies. Alternatively, install Maven 2, use it to build a quickstart WAR file with all the things you need, and then grab the JARs from there. Any of these options would take you a tenth of the time you\\\'ve spent bitching on this mailing list. Yes Maven solves you some problems with dependecies and also si suitable for small project but at big projects it definitely fails. :-/ So
Re: Wicket libraries
Robo wrote: Why there is no complete distribution of jar`s, needed to run Wicket aplication just \out of the box\. it is a little bit boring to find out that I also need to download slf4j and velocity. I uderstand that this info is writen on your page but I would expect just download one tar (zip) unpackit to my classpath write demo and run it. Contrary to lib where one would expect them they are included in example`s war. We give you a ready-to-run WAR file which has all the dependencies for the projects. If we included the JAR files in addition to this, we'd double the size of the download. It's an already-sizeable 14.8Mb for the ZIP. If you use Maven 2, it will manage the dependencies for you. If you choose to manage your dependencies manually, then you will obviously have some work to do. and understand why I need org.apache.velocity packages when I do not use it, is simply confusing me. does Wicket from clear and nice programming go to something unclear and confused? And can someone point me to some link where there is explained why when I develop simple HelloWorld application I need also org.apache.velocity. You don't. You need that for things that use the wicket-velocity project. Such as wicket-examples, which has example code for that. If you want a complete list of dependencies for each project, please find it here: http://herebebeasties.com/static/wicket-dependencies.txt Regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
Hi, You can use maven to build wicket-examples.war which will include all necessary libs. I think mvn war:war should work. I just use maven to download all the dependencies and to generate eclipse project. Then I just open it with eclipse and run the Start class. Piece a cake! Robo wrote: Hello, Why there is no complete distribution of jar`s, needed to run Wicket aplication just \out of the box\. it is a little bit boring to find out that I also need to download slf4j and velocity. I uderstand that this info is writen on your page but I would expect just download one tar (zip) unpackit to my classpath write demo and run it. Contrary to lib where one would expect them they are included in example`s war. and understand why I need org.apache.velocity packages when I do not use it, is simply confusing me. does Wicket from clear and nice programming go to something unclear and confused? And can someone point me to some link where there is explained why when I develop simple HelloWorld application I need also org.apache.velocity. Thank for answers Robert __ Mobilné telefóny v slovenskej premiére a najaktuálnejšie informácie - http://mobil.sme.sk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Klochkov - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Wicket libraries
Hello Al. I worked on some big project where Maven was used(or misused) and form that tme I refuse to solve Maven troubles so Skipping the Maven stuff as this is nto the case: I used to manage dependencies myself and I buil Hello WOrld Application from scratch. Just Hello World. Until I put velocity-1.4.jar and velocity-dep-1.4.jar I have got following errors at deploy time. 5.9.2007 14:31:37 org.apache.catalina.core.StandardContext filterStart SEVERE: Exception starting filter HelloWorldApplication java.lang.NoClassDefFoundError: org/apache/commons/collections/ExtendedProperties at org.apache.velocity.runtime.RuntimeInstance.(RuntimeInstance.java:160) at org.apache.velocity.runtime.RuntimeSingleton.(RuntimeSingleton.java:95) at org.apache.velocity.app.Velocity.init(Velocity.java:106) . 5.9.2007 14:31:38 org.apache.catalina.core.StandardContext filterStart SEVERE: Exception starting filter HelloWorldApplication java.lang.NoClassDefFoundError: org/apache/commons/collections/ExtendedProperties at org.apache.velocity.runtime.RuntimeInstance.(RuntimeInstance.java:160) at org.apache.velocity.runtime.RuntimeSingleton.(RuntimeSingleton.java:95) at org.apache.velocity.app.Velocity.init(Velocity.java:106) . So there is sure dependency in Wicket why developer needs to include these two velocity packages. This is the plus and cons of self managing libraries ... :-) Sure one can find libraries in examples folder but this is not conceptual aproach. I need runtime libraries and expect them exactly where they has to be and not looking for needed libs in examples/demo/tutor directories. There is so much wicket*.jar duplicated libraries that duplicating log4j and velocity is minor in package size question. So if you do not want duplicity do not duplicate even wicket libs, or if you wanrt completness include also libs needed to be wicket usable out of the box :-) Robert - Originálna Správa - Od: Al Maw Komu: Poslaná: 05.09.2007 14:56 Predmet: Re: Wicket libraries Robo wrote: Why there is no complete distribution of jar`s, needed to run Wicket aplication just \\\out of the box\\\. it is a little bit boring to find out that I also need to download slf4j and velocity. I uderstand that this info is writen on your page but I would expect just download one tar (zip) unpackit to my classpath write demo and run it. Contrary to lib where one would expect them they are included in example`s war. We give you a ready-to-run WAR file which has all the dependencies for the projects. If we included the JAR files in addition to this, we\'d double the size of the download. It\'s an already-sizeable 14.8Mb for the ZIP. If you use Maven 2, it will manage the dependencies for you. If you choose to manage your dependencies manually, then you will obviously have some work to do. and understand why I need org.apache.velocity packages when I do not use it, is simply confusing me. does Wicket from clear and nice programming go to something unclear and confused? And can someone point me to some link where there is explained why when I develop simple HelloWorld application I need also org.apache.velocity. You don\'t. You need that for things that use the wicket-velocity project. Such as wicket-examples, which has example code for that. If you want a complete list of dependencies for each project, please find it here: http://herebebeasties.com/static/wicket-dependencies.txt Regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ http://kultura.sme.sk/ - Informačný server o kultúre a šoubiznise - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
Robo wrote: Hello Al. I worked on some big project where Maven was used(or misused) and form that tme I refuse to solve Maven troubles so Skipping the Maven stuff as this is nto the case: I used to manage dependencies myself and I buil Hello WOrld Application from scratch. Just Hello World. Until I put velocity-1.4.jar and velocity-dep-1.4.jar I have got following errors at deploy time. 5.9.2007 14:31:37 org.apache.catalina.core.StandardContext filterStart SEVERE: Exception starting filter HelloWorldApplication java.lang.NoClassDefFoundError: org/apache/commons/collections/ExtendedProperties at org.apache.velocity.runtime.RuntimeInstance.(RuntimeInstance.java:160) at org.apache.velocity.runtime.RuntimeSingleton.(RuntimeSingleton.java:95) at org.apache.velocity.app.Velocity.init(Velocity.java:106) . 5.9.2007 14:31:38 org.apache.catalina.core.StandardContext filterStart SEVERE: Exception starting filter HelloWorldApplication java.lang.NoClassDefFoundError: org/apache/commons/collections/ExtendedProperties at org.apache.velocity.runtime.RuntimeInstance.(RuntimeInstance.java:160) at org.apache.velocity.runtime.RuntimeSingleton.(RuntimeSingleton.java:95) at org.apache.velocity.app.Velocity.init(Velocity.java:106) . So there is sure dependency in Wicket why developer needs to include these two velocity packages. This is the plus and cons of self managing libraries ... :-) You say, until I put velocity-1.4.jar, but if you look at your stack trace, you'll see it's actually bitching about your not having commons-collections (or not the right version at least). It's running code in org.apache.velocity.app.Velocity, which means that it can find that class, which means you're including it from somewhere (i.e. you must have velocity.jar on your classpath already, even if you didn't think you did). That commons-collections class appears to be included by velocity-dep.jar, which is a pretty hideous way of doing things IMO, as it'll probably break things if you include commons-collections separately, etc. Anyway... Wicket categorically does not require Velocity for standard usage. You don't provide a complete stack trace, or any further information about what you're doing. If you did, we might be able to point out why you're having issues. . isn't very helpful. ;-) Sure one can find libraries in examples folder but this is not conceptual aproach. I need runtime libraries and expect them exactly where they has to be and not looking for needed libs in examples/demo/tutor directories. There is so much wicket*.jar duplicated libraries that duplicating log4j and velocity is minor in package size question. So if you do not want duplicity do not duplicate even wicket libs, or if you wanrt completness include also libs needed to be wicket usable out of the box :-) It's not just log4j and velocity. 3rd party libraries for wicket-examples total 6Mb out of the 8Mb in the lib folder. That is not minor - it's 75% of the size of the WAR and thus the distribution, give or take. That said, maybe we should provide a separate ZIP with the dependencies. I guess if you're using Ivy or Maven 2, you're not going to be downloading the ZIP at all. There may be licensing issues with this, though. What do people think? Martijn? Regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
On 9/5/07, Al Maw [EMAIL PROTECTED] wrote: That said, maybe we should provide a separate ZIP with the dependencies. I guess if you're using Ivy or Maven 2, you're not going to be downloading the ZIP at all. There may be licensing issues with this, though. What do people think? Martijn? Including the deps just doesn't increase the size to a double, but a 5 or 6 fold (iirc 65MB). The problem is with transitive deps that are test/compile/provided scope (for instance Spring includes just about the world). The best way currently is to do it as we do now IMO. The current direct deps are license compatible, but I really don't want to check all transitive deps for license compatibility. The current examples is already quite humongous in the dependency department. I have proposed a couple of weeks ago to move examples out of the main distribution, and make it a separate download, and do the same with the quickstart. The benefit would be that the license requirements for the main distribution download becomes smaller, only the stuff we include in the sources ourselves. Both the examples and quickstart would then include all necessary runtime deps for building a wicket application (as described in chapter 3 of wicket in action, and provided with wicket 1.2 until now). This makes them easier to provide a license file for. I just lack the time to make it so. In short: I don't like the idea of adding an all libs project and make it downloadable from Apache. We could make that a wicket stuff project though but the size would resemble downloading a whole maven repository. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
why dont we generate the maven stie somewhere? doesnt that have a list of dependencies for each module? -igor On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: On 9/5/07, Al Maw [EMAIL PROTECTED] wrote: That said, maybe we should provide a separate ZIP with the dependencies. I guess if you're using Ivy or Maven 2, you're not going to be downloading the ZIP at all. There may be licensing issues with this, though. What do people think? Martijn? Including the deps just doesn't increase the size to a double, but a 5 or 6 fold (iirc 65MB). The problem is with transitive deps that are test/compile/provided scope (for instance Spring includes just about the world). The best way currently is to do it as we do now IMO. The current direct deps are license compatible, but I really don't want to check all transitive deps for license compatibility. The current examples is already quite humongous in the dependency department. I have proposed a couple of weeks ago to move examples out of the main distribution, and make it a separate download, and do the same with the quickstart. The benefit would be that the license requirements for the main distribution download becomes smaller, only the stuff we include in the sources ourselves. Both the examples and quickstart would then include all necessary runtime deps for building a wicket application (as described in chapter 3 of wicket in action, and provided with wicket 1.2 until now). This makes them easier to provide a license file for. I just lack the time to make it so. In short: I don't like the idea of adding an all libs project and make it downloadable from Apache. We could make that a wicket stuff project though but the size would resemble downloading a whole maven repository. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
Remember the troubles I had with generating the site? Tim was working on it, but it still is a long shot from being workable. And yes, it has a list of dependencies, but I don't think they generate a link to download each and every one of them :| Martijn On 9/5/07, Igor Vaynberg [EMAIL PROTECTED] wrote: why dont we generate the maven stie somewhere? doesnt that have a list of dependencies for each module? -igor On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: On 9/5/07, Al Maw [EMAIL PROTECTED] wrote: That said, maybe we should provide a separate ZIP with the dependencies. I guess if you're using Ivy or Maven 2, you're not going to be downloading the ZIP at all. There may be licensing issues with this, though. What do people think? Martijn? Including the deps just doesn't increase the size to a double, but a 5 or 6 fold (iirc 65MB). The problem is with transitive deps that are test/compile/provided scope (for instance Spring includes just about the world). The best way currently is to do it as we do now IMO. The current direct deps are license compatible, but I really don't want to check all transitive deps for license compatibility. The current examples is already quite humongous in the dependency department. I have proposed a couple of weeks ago to move examples out of the main distribution, and make it a separate download, and do the same with the quickstart. The benefit would be that the license requirements for the main distribution download becomes smaller, only the stuff we include in the sources ourselves. Both the examples and quickstart would then include all necessary runtime deps for building a wicket application (as described in chapter 3 of wicket in action, and provided with wicket 1.2 until now). This makes them easier to provide a license file for. I just lack the time to make it so. In short: I don't like the idea of adding an all libs project and make it downloadable from Apache. We could make that a wicket stuff project though but the size would resemble downloading a whole maven repository. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
we dont need links, just a list. and i thought the trouble was related to skinning? if thats still the case can we just put a vanilla maven site on wicket-stuff or somewhere? -igor On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Remember the troubles I had with generating the site? Tim was working on it, but it still is a long shot from being workable. And yes, it has a list of dependencies, but I don't think they generate a link to download each and every one of them :| Martijn On 9/5/07, Igor Vaynberg [EMAIL PROTECTED] wrote: why dont we generate the maven stie somewhere? doesnt that have a list of dependencies for each module? -igor On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: On 9/5/07, Al Maw [EMAIL PROTECTED] wrote: That said, maybe we should provide a separate ZIP with the dependencies. I guess if you're using Ivy or Maven 2, you're not going to be downloading the ZIP at all. There may be licensing issues with this, though. What do people think? Martijn? Including the deps just doesn't increase the size to a double, but a 5 or 6 fold (iirc 65MB). The problem is with transitive deps that are test/compile/provided scope (for instance Spring includes just about the world). The best way currently is to do it as we do now IMO. The current direct deps are license compatible, but I really don't want to check all transitive deps for license compatibility. The current examples is already quite humongous in the dependency department. I have proposed a couple of weeks ago to move examples out of the main distribution, and make it a separate download, and do the same with the quickstart. The benefit would be that the license requirements for the main distribution download becomes smaller, only the stuff we include in the sources ourselves. Both the examples and quickstart would then include all necessary runtime deps for building a wicket application (as described in chapter 3 of wicket in action, and provided with wicket 1.2 until now). This makes them easier to provide a license file for. I just lack the time to make it so. In short: I don't like the idea of adding an all libs project and make it downloadable from Apache. We could make that a wicket stuff project though but the size would resemble downloading a whole maven repository. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
Skinning was not a problem, just generating a coherent site with just one command: cd wicket-1.x mvn site:deploy This just doesn't work (tm). Martijn On 9/5/07, Igor Vaynberg [EMAIL PROTECTED] wrote: we dont need links, just a list. and i thought the trouble was related to skinning? if thats still the case can we just put a vanilla maven site on wicket-stuff or somewhere? -igor On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Remember the troubles I had with generating the site? Tim was working on it, but it still is a long shot from being workable. And yes, it has a list of dependencies, but I don't think they generate a link to download each and every one of them :| Martijn On 9/5/07, Igor Vaynberg [EMAIL PROTECTED] wrote: why dont we generate the maven stie somewhere? doesnt that have a list of dependencies for each module? -igor On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: On 9/5/07, Al Maw [EMAIL PROTECTED] wrote: That said, maybe we should provide a separate ZIP with the dependencies. I guess if you're using Ivy or Maven 2, you're not going to be downloading the ZIP at all. There may be licensing issues with this, though. What do people think? Martijn? Including the deps just doesn't increase the size to a double, but a 5 or 6 fold (iirc 65MB). The problem is with transitive deps that are test/compile/provided scope (for instance Spring includes just about the world). The best way currently is to do it as we do now IMO. The current direct deps are license compatible, but I really don't want to check all transitive deps for license compatibility. The current examples is already quite humongous in the dependency department. I have proposed a couple of weeks ago to move examples out of the main distribution, and make it a separate download, and do the same with the quickstart. The benefit would be that the license requirements for the main distribution download becomes smaller, only the stuff we include in the sources ourselves. Both the examples and quickstart would then include all necessary runtime deps for building a wicket application (as described in chapter 3 of wicket in action, and provided with wicket 1.2 until now). This makes them easier to provide a license file for. I just lack the time to make it so. In short: I don't like the idea of adding an all libs project and make it downloadable from Apache. We could make that a wicket stuff project though but the size would resemble downloading a whole maven repository. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
ah, that blows :| -igor On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Skinning was not a problem, just generating a coherent site with just one command: cd wicket-1.x mvn site:deploy This just doesn't work (tm). Martijn On 9/5/07, Igor Vaynberg [EMAIL PROTECTED] wrote: we dont need links, just a list. and i thought the trouble was related to skinning? if thats still the case can we just put a vanilla maven site on wicket-stuff or somewhere? -igor On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Remember the troubles I had with generating the site? Tim was working on it, but it still is a long shot from being workable. And yes, it has a list of dependencies, but I don't think they generate a link to download each and every one of them :| Martijn On 9/5/07, Igor Vaynberg [EMAIL PROTECTED] wrote: why dont we generate the maven stie somewhere? doesnt that have a list of dependencies for each module? -igor On 9/5/07, Martijn Dashorst [EMAIL PROTECTED] wrote: On 9/5/07, Al Maw [EMAIL PROTECTED] wrote: That said, maybe we should provide a separate ZIP with the dependencies. I guess if you're using Ivy or Maven 2, you're not going to be downloading the ZIP at all. There may be licensing issues with this, though. What do people think? Martijn? Including the deps just doesn't increase the size to a double, but a 5 or 6 fold (iirc 65MB). The problem is with transitive deps that are test/compile/provided scope (for instance Spring includes just about the world). The best way currently is to do it as we do now IMO. The current direct deps are license compatible, but I really don't want to check all transitive deps for license compatibility. The current examples is already quite humongous in the dependency department. I have proposed a couple of weeks ago to move examples out of the main distribution, and make it a separate download, and do the same with the quickstart. The benefit would be that the license requirements for the main distribution download becomes smaller, only the stuff we include in the sources ourselves. Both the examples and quickstart would then include all necessary runtime deps for building a wicket application (as described in chapter 3 of wicket in action, and provided with wicket 1.2 until now). This makes them easier to provide a license file for. I just lack the time to make it so. In short: I don't like the idea of adding an all libs project and make it downloadable from Apache. We could make that a wicket stuff project though but the size would resemble downloading a whole maven repository. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
On Wednesday, September 5, 2007, 1:23:42 PM, Robo [EMAIL PROTECTED] wrote: I worked on some big project where Maven was used(or misused) and form that tme I refuse to solve Maven troubles so Skipping the Maven stuff as this is nto the case: If your experience was with Maven 1, then I can understand the feeling, but I should point out that Maven 2 is a completely different experience from M1. It's not perfect, true, but it does do a good enough job that I don't regret switching to it from Ant as my preferred build system, and I'd recommend that you do investigate it again. /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket libraries
not only would the download be bigger, but there would be all kinds of licensing headaches. some jar files might not even be legally distributed in an aggregated download. i also hated maven at first, but you do get used to it and it has gotten a LOT better (even if gosling is still a better concept and foundation for a build system ;-)). Al Maw wrote: Robo wrote: Why there is no complete distribution of jar`s, needed to run Wicket aplication just \out of the box\. it is a little bit boring to find out that I also need to download slf4j and velocity. I uderstand that this info is writen on your page but I would expect just download one tar (zip) unpackit to my classpath write demo and run it. Contrary to lib where one would expect them they are included in example`s war. We give you a ready-to-run WAR file which has all the dependencies for the projects. If we included the JAR files in addition to this, we'd double the size of the download. It's an already-sizeable 14.8Mb for the ZIP. If you use Maven 2, it will manage the dependencies for you. If you choose to manage your dependencies manually, then you will obviously have some work to do. and understand why I need org.apache.velocity packages when I do not use it, is simply confusing me. does Wicket from clear and nice programming go to something unclear and confused? And can someone point me to some link where there is explained why when I develop simple HelloWorld application I need also org.apache.velocity. You don't. You need that for things that use the wicket-velocity project. Such as wicket-examples, which has example code for that. If you want a complete list of dependencies for each project, please find it here: http://herebebeasties.com/static/wicket-dependencies.txt Regards, Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-libraries-tf4383758.html#a12514400 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
