(Courtesy Martin Luther King.)

I have a dream, that software development could be so much easier.

I have a dream, that component oriented practices will conquer the software 
world.

I have a dream, that shows me how we can reach there.


Avalon is not politically correct. We ALL know that, yet we also know that it 
is easier to use COP than EJB, even though the EJB camp have all the tool 
support that we can only dream about. COP is still more efficient.


What if we could get the tool support? 

What if components (free and commercial) were in abundance and only a click 
away?

What if I could search the net, automatically, for a component that fulfill my 
need exactly from within the IDE?

What if our tools could pick 30 components from distributed repositories, and 
have the application running in 15 minutes after download?

What if context sensitive documentation is integrated with the component 
distribution and available immediately within my IDE?

What if components could be updated "live" without bringing the systems down?

What if component configuration is integrated into the IDEs standard 
mechanism, like property pages?

What if it would be possible to consider the network a single computing 
resource, onto which you deploy your application?

What if you could be God of IT?


I believe that Apache Avalon can make this a reality !!!

We are not even that far away !!!
Yes, we are far away from an abundance of components, only time can provide 
that after we have done the infrastructure for it.

By defining strict contracts for components, it is possible to make tools that 
understand these contracts. And we have even started on the tool, 
MerlinDeveloper, and it will become great !

I will be able to do searches for components, using RDF, to find components in 
unknown repositories around the world. Once found, I can drag-n-drop the 
component into the application in question, and with it comes the context 
sensitive documentation, popup Javadocs and all the other nifty features of 
Eclipse.
Component configuration is handled behind the scenes, I don't need to know the 
details, just fill in the form(s).
Some components has special IDE needs, and the IDE plugins for such components 
are available automatically.
Some components have default Web interfaces, which automatically becomes 
available once Merlin is started.
Once the application runs in the IDE, click "Distribute" and a self-contained 
application complete with installation is generated.
There used to be a time when you had to deal with dozens of JARs. That is just 
a memory, who knows what all of that was about.


Just about anything you can think of being a "time consumer" today can be 
solved with better tools.
But the tools can not reason or interpret english descriptive texts of what to 
do, they require contracts, strong contracts, undisputed, irrefutable 
contracts.

Some people don't like the 'rigidness' of strong contracts and says we will 
limit our choice. Damn right!! It is necessary to limit the choices. BUT, it 
doesn't mean we can't evolve the contracts later, or introduce new contracts. 
That is completely within the scope of strong contracts.
My previous post lists some of the contractual areas that I can see that we 
need to tighen up, one of them being "Component Requirements Extension 
Specification" which is all about a specification around how to create and 
evolve specifications in a "Future Compatible" way.

The fluffy hippie days are over, time to get organized, time to become 
efficient, and time to serve our users more than our egos.

* Stringent but extendable component contracts in various areas.
* Leading to self-contained components
* Leading to remarkable tool support
* Leading to flourishing number of components.

I have a dream, that Avalon will step up and make all of this a reality.

And it WILL be FUN


Cheers
Niclas

-- 
+---------//-------------------+
|   http://www.bali.ac         |
|  http://niclas.hedhman.org   |
+------//----------------------+

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to