AspectJ

[COFFMAN Steven <SC...@CBSINC.com>]

AspectJ (http://aspectj.org)
Gak. The license is odious. You can't refer to it in the press? A click
through NDA?

You must provide Xerox with any improvements you make to it, but yet you
can't reverse compile, reverse engineer or disassemble it. Why would you
want to reverse compile it, if it's open source? If it's closed source, how
could you make any changes to it, let alone improve it? NDA + GPL +
Microsoft? Maybe I've got my feathers in a bunch over nothing, but I'm not
accepting *that* agreement. (when you do decline, the site has an error in
processing your request)

Anyway, it seems like basically another closed source, proprietary extension
to the java language, that will die a lingering death like all the others
due to lack of adoption.
-Steve

-----Original Message-----
From: Stefano Mazzocchi [mailto:stefano@apache.org]
Sent: Tuesday, August 08, 2000 10:54 AM
To: fop-dev@xml.apache.org
Subject: Re: Important changes in FOP


Fotis Jannidis wrote:
> 
> Eric:
> > >I'm working on image handling.
> > >I've integrated Pankaj Narula work (package to read image headers:
images
> > >are no longer loaded and kept in memory during the layout process), it
seems
> > >to work well.
> > >I'm also working on the configuration problem (I need a config file for
the
> > >image classes). I use the avalon package, like Cocoon 2 does. But I
need to
> > >modify all FO objects, to make them have access to the Driver (or
> > >FOTreeBuilder) class: the Driver class can load a confi file, but FO
objects
> > >need to access this configuration.
> > >In fact, in Cocoon, all components are constructed with a "manager"
that is
> > >a kind of Hashtable. If a component needs to have access to the parser,
it
> > >calls manager.getComponent("parser").
> > >I think it's a better solution, and want to use it for FOP.
> > >
> > >Any comments, suggestions, ... ?
> > >
> > >PS: I'm still working on it, but I commit my work in a few days.
> > >
> > >Eric.
> 
> Arved:
> > I absolutely, definitely think this should be part of FOP_0_15_0. I'm
> > releasing 0_14_0 very shortly and there is no way we want to postpone it
> > anymore.
> >
> > Let's consider your suggestions and upcoming potential commits as being
the
> > first flurry of work for 0_15_0.
> >
> > I get the gist of your suggestion. One thing I will definitely agree
with
> > is, we need to review and possibly adapt FOP system-wide procedures for
> > accessibility of information. I don't know if what you suggest is the
way to
> > do it - I'm not saying it's not. I guess I could stand to see more
> > discussion on this point.

Of course, my +1 goes for 0_15 not before.
 
> Eric,
> I am not familiar with the Cocoon2 design and have a few questions
regarding avalon.
> I had a (short) look at the avalon documentation
<http://java.apache.org/framework/>. If
> I understand it correctly this is a server framework. Could you explain,
why you think we
> need it?

Avalon is a server framework, true, but contains two component models:
one for servers, and one for server blocks.

A block is, more or less, a collection of objects that implements a
particular logic.

FOP is, in Avalon sense, a Block. Cocoon core is as well.

A server is composed of one or more blocks.

But Avalon has another component model used to componentize blocks, this
is what Cocoon2 currently uses and it's not related to the server side
at all, it's just a collection of classes that simplify the creation of
highly componentized applications (or blocks, for Avalon).

> Or do you just use the configuration part of it? Isn't this linked with a
redesign,
> a partitioning in blocks and components?

Yes, it's already there. You may decide to make FOP implement Block to
make it Avalon-aware, but if you don't there is no overhead and FOP may
live well without having anything to do with Avalon itself.

> At the first look, it sounds like quite a overhead for Fop.

No, rather the opposite: it will make it much easier to developers to
understand FOP internals once they are used to the internal Avalon
component model.

> Going this way could also be a way to handle the MessageHandler problem in
a better
> way. Stefano warned against the use of static methods in the context of
web
> applications, but then I wanted to avoid the overhead, which is necessary
for other
> solutions. If we need it anyway for the configuration design... And we
need a
> configuration framework also for other aspects like adding user fonts.

Totally correct, so this is why I strongly suggest you guys to consider
the Avalon internal component model as a solution for your configuration
and component communication problems.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

Re: AspectJ

[Stefano Mazzocchi <st...@apache.org>]

COFFMAN Steven wrote:
> 
> AspectJ (http://aspectj.org)
> Gak. The license is odious. You can't refer to it in the press? A click
> through NDA?
> 
> You must provide Xerox with any improvements you make to it, but yet you
> can't reverse compile, reverse engineer or disassemble it. Why would you
> want to reverse compile it, if it's open source? If it's closed source, how
> could you make any changes to it, let alone improve it? NDA + GPL +
> Microsoft? Maybe I've got my feathers in a bunch over nothing, but I'm not
> accepting *that* agreement. (when you do decline, the site has an error in
> processing your request)

You know how careful I am with licensing issues and I have _not_
overlooked those ones with AspectJ.

I restate a little: IMHO, AOP is the future of OOP and AspectJ is just
one implementation of AOP for the Java syntax.

Avalon is another (even if we have very very little AOP capabilities
with the Avalon policies).

I'm *not* suggesting we use AspectJ to write FOP, heck no way! But I'm
working in close contact with the Xerox team that is designing AspectJ
and they are porting Cocoon2 to AspectJ to have a real life feedback.

The license they are using is (I presume) the standard
"we-are-still-designing-this-so-don't-hook-to-it-nor-write-articles°
type of license Xerox has.

All the people I've been talking with are _extremely_ friendly and
behave just like AspectJ is one true open contribution to the Java
community.

I even ventured to propose Xerox to donate AspectJ to the ASF under APL,
but they want to finish design first (they have version 0.7b2 right now
and they want to reach 1.0 before doing anything different).

> Anyway, it seems like basically another closed source, proprietary extension
> to the java language, that will die a lingering death like all the others
> due to lack of adoption.

They clearly know that without openess any java extention is going to
die of sudden death, not matter how good and powerful.

Don't underestimate the power of good ideas,if mixed with some true ASF
visionaires :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------