Not sure if you are actually taking user requirements or not, but here is my .02.... I agree with Kasper's comments on the naming madness, but cannot actually offer suggestions at the moment :-) Documentation: I have read quite a bit of the discussions on "What is Avalon" and others, and from a user's perspective, I really, really like Avalon and (as I've mentioned before) am promoting it internally for our product. Having said that, the biggest 'problem' I've seen is lack of really good documentation, which I'm sure no one will really argue with, and a confusion with all the various sub-projects and half done, forgotten(?) and/or not mentioned components that I find in CVS. Now, I have volunteered to do some doc work (I fixed link #2 about 2 months ago Kasper...), but stopped for a couple of reasons (but I would really like to continue): - First and most important is direction. With all that is changing I really don't know where to go and it doesn't seem there is anything solid right now from which to work (am I wrong?). An example is the ComponentManager code examples, which should now move to ServiceManager, but what container uses SM? I know that is a relatively simple question, but you (hopefully) get the idea. - Second (and I admit I didn't follow this closely) was there seemed to be some changes in the structure and/or generation of the site. - Third, when will the site be updated?? On Containers: I've kind of lost track of the discussions on the various containers, but it would be nice if there were either some consolidation on these, or at least what is really available and at what scale. I know about Phoenix, ECM (which is going by the wayside as I understand it), Fortress (no experience), Merlin (no experience), and I've forgotten probably one or two... >From a useability point of view, I would caution against the 'ultimate' container and setup. You would probably run into the eventual problems that face EJB servers now, namely hard to configure and use. I currently use ECM because it was simple to use and I don't mind moving to its eventual replacement as long as it is simple to use as well. I don't mind config files and meta-data, but please make the container APIs easy to use. I've seen all the discussions about what to do with ComponentManager, release(), lookup(), etc. and personally from my perspective I don't care as long as it remains fairly simple to use. If I were one of the developers of course I would care as those things are important, so I would agree that coming up with the API should take some thought and not be changed in every version that comes out. Components: While I realize that the core APIs are being discussed heavily, what's up with all the other 'stuff', such as the Cache pckg (is there an actual component there?), Monitor, naming, etc. Which components are ready for use? Maybe having something on the site saying that component XYZ is 'certified' for use with Avalone 4.x, 5.x, Phoenix, Fortress, etc. would be really nice instead of just saying that XYZ is available in CVS. Examples: I really like the idea of a dev. kit with examples and such. I know this would take some work, but would be really helpful for newbies. Market Penetration: Of course any good publicity would be wonderful, and I've actually approached my boss about writing an article about Avalon and our use of it. - Robert McIntosh -----Original Message----- From: Kasper Nielsen [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 27, 2002 1:03 PM To: Avalon Developers List Subject: Re: [Vote] User requirements for A5 > > Might as well start somewhere: Kasper, what would you like to see in > A5? > > /LS cool 1. End to the naming madness Excalibur, Phoenix, Cornerstone,.... It takes me about 2 min from when I read the description of each to when i've forgotten what the names cover, why not call Phoenix -> AvalonApplicationServer (AAS) , Cornersone -> AAS Services, ... or something else meaningfull. Giving each top project on jakarta a 'funny' name is great, but giving every subproject in every topproject a 'funny' name is confusing. You know people sometimes have a problem separating Turbine and Velocity (Turbine questions on the Velocity mailing lists and Velocity questions on the Turbine list). If people aren't able to separate these two projects, � doubt they will be able to separate the various Avalon sub-projects 2. Create a Avalon Development Kit (we have it in Turbine land and its called TDK ) ADK should contain - all Jar's needed to develop a project, - a couple of examples. - All API documentation + manuals - They must be a quick way to start a new project something that would only require something like 'ant newproject' and it would create a directory structure, setup a build.xml file, copy the jars needed, ... a simple ant script and newapp.propertyfile is all that is needed. 3. JSR 111 Someday the Java Service Framework is going to show up. A5 needs to compatible in some way to it. And people needs to be aware of it. I saw that you Berin (and Paul) is in the Expert group whats the status? 4. Market Penetration (or the lack of it) Some articles in javaworld, sdmagazine, TheServerSide would do wonders for letting people know that avalon exists. 5. Logkit People are worried about using technology that doesn't comply with standards, having a subproject entirely devoted to logging could make people believe that they are taking the path directly to the dark side. If I first discovered Avalon (and logkit) I would also think it was out of date since it doesn't mention jdk 1.4 logging 6. Webservice Okay its a buzzword, but everybody body is talking about it, how can I easily make my components into a webservice btw 1. why don't remove the link to Testlet, it was discontinued on 1. august 2001, im sure nobody uses it anymore. 2. The link to jakarta main on http://jakarta.apache.org/avalon/ should point to http://jakarta.apache.org/ - Kasper -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
