Robert Simmons wrote:
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.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.
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.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?"
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.
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.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.
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.3) Componetize optional features. Give them separate configuration files and keep them separate.
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.
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.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.
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.
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.
Some of the facilities that you wanted aren't available or as complete in the released binary; That's why some folks pointed you to CVS. 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. 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. :-/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.
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.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.
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]>
