> Robert Simmons wrote: > > >GOOD! This is my idea of the right attitude. People seem to fail to realize that > >if I didn't see the potential of the product, I wouldn't bother wasting several > >hours of my time typing up very long emails on the subject. > > > I can see that you do indeed care, but (for example) Slashdot is full of > long messages from people who don't care about the livelihood of a > particular project. This isn't you, I just couldn't resist making that > point -- no offense intended. Your statement makes assumptions that we > already know you as a person.
I don't use slashdot for the very reason that its full of allot of backseat drivers. You will just have to trust me when I say my internl deadline clock is cringing at me wasting 2 days typing emails. > >1) A deployment version with one jar containing all the required CORE libraries > >in that jar. This jar would contain avalon and excalibur and the rest but > >wouldn't bother to mention it. That would stop "jar shock" that the newbie > >encounters when popping open the web-inf/lib directory. I think my exact words > >were, "Holy shit?!?!? What do I really need?" > > > > If you consider a .war as an atomic unit, it's unnecessary. But it can > seem intimidating, you're right. Then again, how often have you gone > into the lib directories of JBoss or Tomcat? Those aren't exactly sparse. Never bothered to look .... loooking .... nope. Looks nasty. But then notice the "Ive never bothered looking." Despite using JBoss for near 2 years now. In cocoon, I HAVE to look. > On another note, it could well be argued that Cocoon is far more complex > than Tomcat, so I'd be unsure whether this was a fair comparison. > Cocoon actually seems to be straddling the line between servlet and > container. I think many long-time users and the developers see that, > but as a newbie, you see the "servlet" moniker and have unrealistic > expectations. I don't actually think it's anyone's fault per se; it > really is quite difficult to explain something that doesn't fit well > into existing definitions or practices. Be that as it may, first > impressions are first impressions. Peachy. But users dotn really care about what line its stradling. They care 1) does it work?. 2) is it scalable? 3) does it require you to be a developer to use it? 4) how fast can i get it running. Save the speaches about what lines its straddling for the developers and the people concerned about learning its architecture. The users dont care. > >2) A single built war file with hello world. All it does is spit out hello world > >through a little XSLT template. That's it. This is where newbies want to start. > >Start small and work your way up. > > I believe there are folks working on that particular issue. It was > asked for previously on the mailing lists (a skeleton sitemap in a > relatively bare Cocoon instance) and there are many others that share > your concern. It really isn't apathy that you see but a work in > progress. There are some who may have taken your statements as > indictments of their (volunteer) work when it's a known problem on the > todo list. Hmm, I find it strange if this isnt just some ant work to accomplish. Why isnt it there? If it is truly such a time consuming task as to not have been provided yet (though critical) then you rather prove my point. If the devs dont have time to get this fired up, how the heck does someone who knows nothign about it stand a chance? > >3) Componetize optional features. Give them separate configuration files and > >keep them separate. > > This is already well underway in the "blocks" concept. This is a > relatively young endevour, so you would have to read the developer > mailing list archives to get specific information. As a quick preview > though, if you built a copy of Cocoon CVS and looked in the WEB-INF/lib > directory of the .war file, you would see quite a few .jar files with > "block" in the name. This is the beginnings of what you propose and is > a work in progress. Good news there. > >4) Change the distribution. You get either a minimal (which is required stuff > >+hello world) or medium (which contains some samples) or kitchen sink (the > >current distribution). > > > > Been proposed before and is on the todo list. Again .. if this isnt a small amount of work, somethign is seriously wrong. If it is a small amount of work and not a priority than you can see where newbies are comming from. Focusing on features is all well and good but if you dont get people to adopt the technology, you are hosed. You can bet Microsoft is examining cocoon right this mometn and trying to figure out if they can make an easy to use package that does the same thing. > >5) Remove anywhere where cocoon user has to know about avalon or excalibur. Most > >of us don't much care. When we write a generator we want to implement an > >interface and say "uhh, my generator is here with this class name" and go with > >it. If I need to mount more than one jar, something is borked. Basically just > >facade all the entry points into cocoon with interfaces. its low a low budget > >task that goes a LONG way. > > Technically you never mount a .jar file; You only really deploy a .war > file (or a .ear file in the case of EJB containers). At any rate, with > Cocoon in development (many times a state of flux), having each piece > separate makes debugging and development quicker and easier. When Im talkign development, Im not talking about development OF cocoon. Im talking about devloping of my custom generators and so on to be sitting on top of cocoon. In which case, in order to compile, Id nee to mount some jar into my netbeans project forthe imports to work. That or stuff it in an ant build. > If you need more than one jar, nothing is "borked." It all works just > fine as separate files. This is an aesthetics issue (extending into > mild intimidation), not a technical one. Putting everything into a > single jar won't make Cocoon run better -- it will simply appear > "neater" to some. Yep. WOAH!!! My answer is "YEP." Thats got to floor ya. But you see what you see as aesthetics, the newbies to cocoon see as a vicious growling dog with sharp teeth. Does it matter that this dog is just playing and has no intention to bite? Nope. You just run. HIDE EVERYTHING the user shouldnt be screwing with. > As for Avalon and Excalibur interfaces (and components), the idea was > that many of these resources are not Cocoon-specific and should be > shared outside the context of a single webapp. Weren't you just > vehemently recommending the use of log4j? Isn't that including another > outside package dependency? I see the issue here as one of > documentation/education more than technical deficiency. Avalon and Excalibur are primarily used in jakarta projects. For one reason or another they havent hit mainstream. In addition they are both very old java libraries going back at leat 4 JDKs and I can immagine some of it is now in the JDK. At any rate, Im a cocoon user, not an avalon user. One technology at a time. should I decide to pick up avalon, I can download it and start learning it as well. Dont try and pull a Microsoft here. Microsoft uses the strategy, "well now that you are using one of our products, you need to use them all." Open source cant pull off that trick. in fact only a monopoly can. > >6) Remove any need to build from CVS. I downloaded the module, all 61 megs of it > >and now I expect to spend 20 hours to just get a minimal build working. Users > >don't want to have to build the product. Maybe 1% of ant users ever bother to > >build it. Same for tomcat and the other popular apache products. > > Some of the facilities that you wanted aren't available or as complete > in the released binary; Like what? All I wanted was to drop a static XML and XSL hello world and see a server side transform. That feature isnt in the release? > That's why some folks pointed you to CVS. CVS isnt always an option. Convincing management to put up a beta in production is hard enough. Tellign them you are goign to deploy a protentially unstable bleeding edge application to serve their sales site witll prolly get you fired. > There are also some speed/efficiency wins. There isn't much anyone can > do about that unfortunately. You want it "right now" and some things > simply aren't ready for release. If all you want is a simple Hello > World example in Cocoon 2.0.4, I can give you a barebones sitemap if you > like. It requires that you unpack the .war, erase the content, plug in > a few files, and repackage the .war file. Ohers have offered this. I appreciate it. However it should be somethign generally available. > Alternatively, because Tomcat > can access webapps by directory as well as by .war file, you wouldn't > necessarily have to repackage the .war file in order to test and fiddle > around a bit. It's not a perfect solution, but I don't know if you will > get a perfect solution according to your criteria right now. :-/ I use JBoss. Tomcat is merged with it in ways that I dont particularly care about. End of story. Many potential users of cocoon will be people like me who are looking to deploy powerful polymorphic fron ends to sophisticated back-end distributed software. EJB is a REVOLUTION in server side engineering. Thanks to it and JDO, Id have to go fish around for a SQL manual to write a search. I dont bother with SQL anymore. > >7 and not a priority but would be nice) Change logging to use Log4j. Its won the > >race. Even the logging in jdk has been beaten bloody by log4j. The other logging > >frameworks might as well concede. > > Unlikely to change at this point. Most of the time, you don't have to > write Java code anyway (eg. LogTranformer) so you wouldn't necessarily > see it. When accessing logging as a component, it's not clear that you > are using Logkit (or any other package by name). In addition, many of > the same constructs are there so if you are familiar with log4j, the > logging API used in Cocoon should pose no challenges. But after all is > said and done, there is absolutely nothing stopping you from using log4j > in your own components if you are set on that goal. Possibly but people now have huge production systems using Log4j. They like to have one framework in whihc everythign is logged. Log4j has won the race so brutally that the logging in JDK 1.4 was basically laughed out the door. > > Bear in mind, I am not a committer. I am only a user. I speak only for > myself. I understand where you are coming from and I truly sympathize > with your difficulties, but your tone carries expectations that these > things will be solved in the timeframe you have deemed necessary. This > is unlikely not because of lack of caring or because of any overt > animosity; This is because even though many people agree with a good > portion of your statements and suggestions, the work needs to get done > by people. People need time. The things you have asked for are things > that others have asked for and are things that people have taken an > honest interest in improving. > > Also bear in mind that many people on these lists don't speak English as > their first language. Just as acidic sarcasm comes off as ridiculously > rude in many other countries/languages, some other languages have a > fatalistic tone to them and translate to English as "that's just how > things are." Americans hug and the French kiss -- substitution is often > taken as an invasion of personal space. There needs to be a little > flexibility taking this into account. > > And please believe that if I didn't care, I wouldn't have bothered > writing this long email. ;-) > > - Miles > > > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
