excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Harrah <matt.har...@platinumsolutions.com>
Subject Re: Lowering the barrier to Excalibur
Date Wed, 09 Mar 2005 18:40:31 GMT
Things I'd like to see:

1) A configuration analyzer tool with 

a) the ability to visualize/navigate/inspect the configuration, ideally
both at run-time and at design time, but I'd settle for either

b) useful, human-readable help for resolving problems and not just
identifying what went wrong. For example, if you have no class for a
given role, it would be great if there were something that told you
exactly what the container were looking for and why, and what steps
could be taken to fix the problem (add xdoclet tags, fix classpath,
create the class with the role, etc). If this can't be done in a tool,
some documentation of this would be better than nothing.

c) the ability to produce documentation of the configuration

d) the ability to validate a configuration's cross-references without
having to spin up the full container

2) Documentation that is more task-oriented and less class-oriented.
Javadoc is great, but it is never going to work for barrier-lowering
documentation. If I am a beginner, I have no idea what class to look in.
I know what I want to accomplish.

On Mar 09, 2005 10:31 AM, J Aaron Farr <jaaronfarr@gmail.com> wrote:

> We've mentioned the need to make developing with Excalibur easier
> several times on this list.  I've been thinking about ways to do this
> and here are some of my suggestions:
> 1. A series of short tutorials:  We could create a couple short
> tutorials/introductions somewhat like Picocontainer's "One minute
> description,Two minute tutorial,Five minute introduction" set.  These
> could be placed in the wiki.
> 2. Maven plugins like Turbine's META [1]: What about creating a maven
> plugin that could setup a Fortress or ECM development environment in
> one command.
> 3. A simple binary distribution: Unzipping the distribution would give
> you all the libraries, example configuration files and the Java
> Service Wrapper already setup.  Maybe you could have a couple
> versions: a lightweight distro which only has a trivial example
> included versus a "Kitchen Sink" distro that shows how you can tie
> several components together.
> 4. Eclipse Plugins:  I'm doing some plugin development now and maybe
> later this year I can write some custom editors for role and
> configuration files or for generating meta-data or maybe even a
> graphical editor for wiring up the container (drag and drop the
> component roles).  I'm not sure what type of plugin would be useful,
> so I'd appreciate some ideas.
> Also, I think we need to emphasize our relationship with other
> existing projects more like Turbine, Keel, Cocoon, Xingu, etc. hammett
> recently said:
> >I think Spring is twenty years ahead of what we have here - in the
> >sense of
> >speeding up the development.
> Well, perhaps.  But perhaps not when you consider Turbine and Cocoon
> and all these other projects which use Excalibur.  If we can help
> users leverage these other libraries and refine Excalibur as an easy
> to use common platform, then I think we're not in such dire straits.
> Thoughts?
> -- 
>   jaaron
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org

Matt Harrah
Senior Consultant, PlatinumSolutions, Inc.
Two Discovery Square, 12012 Sunset Hills Road, Suite 445
Reston, VA 20190    PH: 703.471.9793  FAX: 703.637.4464 

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the email by you is prohibited.	

To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org

View raw message