You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/11/25 19:01:51 UTC
[RT] What about Magic and Avalon?
Leo Simmons posted a nice little essay that should be referenced prominently,
although maybe tempered a little? Obviously, Leo has encountered too many
applications that suffer from this overzealous application of magic. However,
it begs some serious questions that we might want to look at with Avalon.
1) Are we going too far down the rabit hole, as it were? If so, where and how
do we fix it?
2) How does a project that *is* a framework embrace such an outlook--carefully
balancing what the framework is supposed to do and increase maintainability
and debuggability (new word...) of applications built on it.
For instance, I like attributes, as it solves some very real problems with
component management--although their use does provide some serious issues
that need to be addressed.
Along with the introduction of attributes, and special config files, etc.,
making an application built with these tools work with a storebought IDE is
difficult. I have really learned how to work with a debugger in the past
few years, and creating a plugin just to make the application run is not
really that cool.
We need to compile the attributes at compile time, and be able to work with
the IDE's supplied classloader--which means scanning JARs is not really a
good option in this environment. This is sort of a catch 22. Attributes
not only solve a number of management issues, they introduce a host of new
issues. Does this mean I consider them a failed experiment? No. I don't.
I do see that if we are going to use these tools, we need a better way of
using them in IDEs.
We can create a plugin when JSR 198 is done that would allow for this to happen,
but what about now? We would need to write at least three plugins to get 90%
of the users out there. I need JBuilder for work, but I really like IDEA for
my own use. A large number of folks use Eclipse due to its attractive price
tag.
With my GUIApp framework that I am developing, just getting it to run inside
an IDE is a real chore. I have to use remote debugging just to see what is
going on inside of it. Much of this is due to the magic with the classloader
and attributes.
How would we simplify this conundrum? We could wait for JDK 1.5 and get what
we really want as a language feature. But that doesn't help us now. How do
we make Merlin easier to understand?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] What about Magic and Avalon?
Posted by Serge Knystautas <se...@lokitech.com>.
Leo Simons wrote:
> I suck at statistics. I added big fat disclaimers. Don't read anything
> into it. Its bogus. Only considering, for example, that every pico
> sourcefile has 5 lines of license header, and we have like 25.
>
> What would be useful? We could do some work on that. But I doubt it'd
> help us get anywhere.
Check out JavaNCSS... it counts the # of non-commented source lines in
Java code. That would address the # of license header lines.
--
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] What about Magic and Avalon?
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> Leo Simons wrote:
>>
>>> Lies, damn, lies, and some statistics:
>>>
>>> Files Lines
>>> -------------------------------------
>>> Pico | 164 8495 51
>>> Fortress | 433 26115 60
>>> Phoenix | 924 69230 75
>>> Merlin | 2130 88623 41
>>
>>
>> Interesting - now how about turning this is something at least
>> approaching anything useful.
>
>
> I suck at statistics. I added big fat disclaimers. Don't read anything
> into it. Its bogus. Only considering, for example, that every pico
> sourcefile has 5 lines of license header, and we have like 25.
>
> What would be useful? We could do some work on that. But I doubt it'd
> help us get anywhere.
Use a Jdepend analysis on it. It does things like cyclic dependency checking,
code complexity checking, as well as a SLOC count. SLOC is Source Lines of
Code--so it skips comments and catches things like two commands on the same
line.
For instance:
/* really long line */ int i = 2; i *= 32; i <<= 4;
in your approach would be counted as one line, but with a sloc count would be
three lines.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] What about Magic and Avalon?
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> Leo Simons wrote:
>
>> Lies, damn, lies, and some statistics:
>>
>> Files Lines
>> -------------------------------------
>> Pico | 164 8495 51
>> Fortress | 433 26115 60
>> Phoenix | 924 69230 75
>> Merlin | 2130 88623 41
>
> Interesting - now how about turning this is something at least
> approaching anything useful.
I suck at statistics. I added big fat disclaimers. Don't read anything
into it. Its bogus. Only considering, for example, that every pico
sourcefile has 5 lines of license header, and we have like 25.
What would be useful? We could do some work on that. But I doubt it'd
help us get anywhere.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] What about Magic and Avalon?
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>
> Lies, damn, lies, and some statistics:
>
> Files Lines
> -------------------------------------
> Pico | 164 8495 51
> Fortress | 433 26115 60
> Phoenix | 924 69230 75
> Merlin | 2130 88623 41
Interesting - now how about turning this is something at least
approaching anything useful. Merlin has a *lot* of documetation -
working tutorials - etc. Then ask yourself how the term "magic" is used
as a substitute for plain old documentation.
:-)
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] What about Magic and Avalon?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 26 November 2003 07:06, Alexis Agahi wrote:
> BTW 2130 files!
> I understand why it take 5 minutes to build with maven ;)
And only 45 seconds with Ant ?
Couldn't help it ;o)
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] What about Magic and Avalon?
Posted by Alexis Agahi <al...@users.sf.net>.
On Tuesday 25 November 2003 21:07, Leo Simons wrote:
> Files Lines
> -------------------------------------
> Pico | 164 8495
> Fortress | 433 26115
> Phoenix | 924 69230
> Merlin | 2130 88623
Dont you think comparing Pico and Merlin is just like comparing AWT and SWING?
:)
Both target specific applications. This does not mean that one is better than
another.
Personnaly I dont find Merlin really hard to learn (I mean, not as much as
Fortress or Phoenix or the Framework itself). Merlin offers lots of features
(and I agree that most of them may not be used be a common simple
application), but this does not mean that you have to be aware of them.
Does anybody here know perfectly the whole JDK1.4 API? :))
BTW 2130 files!
:o
I understand why it take 5 minutes to build with maven ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] What about Magic and Avalon?
Posted by Vincent Tence <vt...@pyxis-tech.com>.
> What should we do? The answer to that is actually a simple one, Berin!
>
> Just make sure that your code only references, and works with, other
> java code. Make sure all your 'language extensions', all your magic,
> should be able to map to and from (and be replaced by) java code,
> directly, intuitively.
<snip/>
> what you have here is 'optional' magic. You can remove your attribute
> compiler and your attribute metadata by replacing it with pure java
> code. When you write unit tests, when you debug your code, when you
> deploy to a constrained environment, you replace your fancy stuff with
> the pure java.
>
> I don't feel much like continuously referring to PicoContainer, but this
> is a pattern consistently followed there. You normally want to use some
> kind of xml declaration of your components (or a script, or an automatic
> classpath browser, or ...), but those are *optional*. PicoContainer is
> built around being able to replace the xml, the scripts, all that, with
> plain and simple java code.
I think Leo really has an *excellent* point here. What's really nice with
Pico
is it's ability to run with or without the magic. They just separated the
concern of doing the thing - in plain java - from the concern of making
it easy to use the thing - with magic. And it has great implications on
the internal design and testability of Pico, as well as on its level of
acceptance by the Java Community - what I mean here is that Pico is less
frightening thus more accepted.
<snip/>
Leo, please keep up the good food for the brain ;-)
- Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] What about Magic and Avalon?
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> Leo Simmons posted a nice little essay that should be referenced
^^ Simons
> prominently, although maybe tempered a little?
KISS. Say one thing and say it well. Going a little over the top is more
thought-provoking and more fun to read (IMHO). There is always a balance
to be found in Real Life(tm) :D
> 1) Are we going too far down the rabit hole, as it were? If so, where
> and how do we fix it?
I know I've repeatedly crusaded against all the complexity in merlin.
What you need to realise is that different use cases demand different
complexity. Now, Merlin is being developed according to a set of complex
requirements for a complex solution to a complex problem.
The catch: many of us don't have those complex requirements. My apps are
an order of magnitude (or two) simpler than the things Steve works on.
Thus, for me, merlin is too much magic, while for him, its the only
thing that will allow him to get his stuff in place before the 22nd century.
> 2) How does a project that *is* a framework embrace such an outlook--
> carefully balancing what the framework is supposed to do and increase
> maintainability and debuggability (new word...) of applications built
> on it.
I think it can only be done with lots of discipline and slow addition of
features. Only add support for something once you have arrived at a
point in your framework-using application that cannot be solved otherwise.
That, however, is often a much more difficult (at least for me) way of
designing. It takes longer.
> For instance, I like attributes, as it solves some very real problems with
> component management--although their use does provide some serious issues
> that need to be addressed.
>
> Along with the introduction of attributes, and special config files, etc.,
> making an application built with these tools work with a storebought IDE is
> difficult. I have really learned how to work with a debugger in the past
> few years, and creating a plugin just to make the application run is not
> really that cool.
indeed! The thing to realize is that, everytime you add some kind of
magic, you're introducing some kind of language extension. And the
problem with language extensions is that they are extensions, hence *not
standard*.
Remember the flamewars about making metadata a part of the 'core
framework' vs. it being an extension? If it is not part of the generally
accepted core, its use is problematic. If it is, other things are
hampered (like the ability to use your stuff in a "pure" java environment).
> We need to compile the attributes at compile time, and be able to work with
> the IDE's supplied classloader--which means scanning JARs is not really a
> good option in this environment. This is sort of a catch 22. Attributes
> not only solve a number of management issues, they introduce a host of new
> issues. Does this mean I consider them a failed experiment? No. I don't.
It is not just attributes. It is everything that is not "pure",
"standard" java code that is compiled into classfiles. XML configuration
files. Manifest files. Property files.
What should we do? The answer to that is actually a simple one, Berin!
Just make sure that your code only references, and works with, other
java code. Make sure all your 'language extensions', all your magic,
should be able to map to and from (and be replaced by) java code,
directly, intuitively.
In the attribute example, create an object model for attributes, and use
that in your components. Make sure your runtime support layer is
flexible enough that you can use manual method calls on it to build the
attributes. In fact, make your fancy attribute parser into something
that does nothing but do these method calls for you.
Consider (just making something up here)
/** @@ComponentClass( "SomeComponentImplementation" ) */
class ComponentFactory
{
Object newInstance()
{
String className = AttributeUtil.getAttributes( this.class )
.getAttribute( ComponentClass.class ).getClassName()
return Class.forName( className ).newInstance();
}
}
The only thing you need to make sure is that you can add in the
attribute by hand as well. Like this (again, just a stupid example):
AttributeUtil.addAttribute(
ComponentFactory.class,
new ComponentClass( "SomeComponentImplementation" ) );
what you have here is 'optional' magic. You can remove your attribute
compiler and your attribute metadata by replacing it with pure java
code. When you write unit tests, when you debug your code, when you
deploy to a constrained environment, you replace your fancy stuff with
the pure java.
I don't feel much like continuously referring to PicoContainer, but this
is a pattern consistently followed there. You normally want to use some
kind of xml declaration of your components (or a script, or an automatic
classpath browser, or ...), but those are *optional*. PicoContainer is
built around being able to replace the xml, the scripts, all that, with
plain and simple java code.
> How do we make Merlin easier to understand?
I spent an hour or two looking at the code today, and I must say I
haven't got a clue.
Lies, damn, lies, and some statistics:
Files Lines
-------------------------------------
Pico | 164 8495
Fortress | 433 26115
Phoenix | 924 69230
Merlin | 2130 88623
that includes all non-code files as well, all comments, all unit tests,
all license headers (see below for how I got these figures). Merlin is
roughly 10 times the size of Pico. Based on that, I will assert that it
is at least sqrt(10)=~3.16 times as difficult to understand (yes, that
is a complete bogus figure which has no basis in science).
cheers!
- LSD
Statistics gathering
-----------------------------------------------------------------------
[lsimons@giraffe merlin]$ pwd
/home/lsimons/cvs/avalon/merlin
[lsimons@giraffe merlin]$ find . -type f | grep -c '.*'
2130
[lsimons@giraffe merlin]$ find . -type f -exec cat \{\} \; | grep -c '.*'
88623
[lsimons@giraffe avalon-phoenix]$ pwd
/home/lsimons/cvs/avalon-phoenix
[lsimons@giraffe avalon-phoenix]$ find . -type f | grep -c '.*'
924
[lsimons@giraffe avalon-phoenix]$ find . -type f -exec cat \{\} \; |
grep -c '.*'
69230
[lsimons@giraffe fortress]$ pwd
/home/lsimons/cvs/avalon/fortress
[lsimons@giraffe fortress]$ find . -type f | grep -c '.*'
433
[lsimons@giraffe fortress]$ find . -type f -exec cat \{\} \; | grep -c '.*'
26115
[lsimons@giraffe pico]$ pwd
/home/lsimons/cvs/pico
[lsimons@giraffe pico]$ find . -type f | grep -c '.*'
164
[lsimons@giraffe pico]$ find . -type f -exec cat \{\} \; | grep -c '.*'
8495
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org