RE: [stellation-res] Using AspectJ?

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> >Chu-Carroll
> >Sent: September 8, 2002 4:30 PM
> >To: stellation-res@xxxxxxxxxxxxxxx
> >Subject: Re: [stellation-res] Using AspectJ?
> >
> >
> >On Sat, 2002-09-07 at 01:50, Florin Iucha wrote:
> >> On Fri, Sep 06, 2002 at 03:22:22PM +0000, Mark C. Chu-Carroll wrote:
> >> > On Fri, 2002-09-06 at 13:08, Dave Shields wrote:
> >> > > On Thu, Sep 05, 2002 at 03:03:23PM +0000, Mark C.
> >Chu-Carroll wrote:
> >> > > > So I'd like to know what people think about the idea of adding
> >> > > > AspectJ to our suite of tools.
> >> > > I am wary of tools that require a change to the source so
> >that is no longer
> >> > > in standard Java. For example, our earlier experiment with
> >gj, while producing
> >> > > more readable code, had the following drawbacks:
> >> > >
> >> > > 1) Since we could no longer use Jikes, compilation time
> >went up by a factor of 3-5.
> >> > > I *really* enjoy being able to compile the full system in
> >under five seconds
> >> > > real time.
> >> >
> >> > On the one hand, I do sort of agree with you. The Stellation
> >core should
> >> > be compilable from the command line. And it's definitely valuable for
> >> > that to be efficient.
> >>
> >> If that "should" is not a "must", I change my vote to -1.
> >
> >Don't overparse my words, I'm a pretty straightforward guy.  Yes, I
> >intended that line to mean that I consider it a strict requirement
> >that the Stellation core be compilable from the command line, using ant.
> >
> >> The core stellation (the server + command line tool) must be compilable
> >> from the command line. For the eclipse plugins, I don't have a strong
> >> opinion as they requre eclipse by definition.
> >>
> >> > But on the other hand, I think relying too much on a
> >command-line based
> >> > work environment is going to become more and more of a problem.
> >>
> >> Nope. Relying on buttons to do the work is a problem. A command line
> >> tool you can invoke from cron to compile, run the tests over a server
> >> farm and mail the results so you can digest them in the
> >morning. Try doing
> >> that with a GUI.
> >
> >Sorry, but my point still holds. Significant parts of our system are
> >in Eclipse plugins, and that will be increasingly true over time. If
> >you *exclusively* rely on command-line compilation, there is no way for
> >you to know if you've made a change that breaks the Eclipse plugins.
> >
> >For example, most of the time when Dave makes API changes in the
> >workspace, it breaks something in Jim's plugins, which are clients of
> >that API. So far, that hasn't been a big deal. But as more and more
> >functionality is implemented in the plugins, it's going to become
> >a big deal, and it's going to be necessary for anyone who changes the
> >core to verify that the changes they're making don't break anything
> >else.
> >
> >It would be nice if there was a way to trigger an Eclipse compilation
> >cycle from the command line; and I've heard rumours that there's a
> >way to do it. If we can run an Eclipse builder from the command line,
> >then great. But at the moment we can't - and that means that it's
> >really a requirement that developers at least periodically do a
> >build within Eclipse.
> >
> >
> >> >
> >   Because
> >> > so much of the code we'll be adding is going to be in the form of
> >> > Eclipse plugins, which *can't* be compiled from the command line.
> >>
> >> I surely hope that does not include the fine-grained artifact
> >> manipulation. If you rely on a running eclipse to do the parsing then
> >> stellation is much less usefull.
> >
> >We *are* going to rely on Eclipse to do the parsing. Sorry. As usual,
> >if you disagree with us, you're absolutely welcome to work on
> >a non-Eclipse based version. And if it works better than the
> >Eclipse-based one that I'll be building, we'll let the full group
> >of developers decide which one to use.
> >
> >Let me take a moment to explain how I'm planning on doing things,
> >and then you can feel free to praise, criticize, or flame as you
> >feel appropriate.
> >
> >The main goal of the Stellation project is to build
> >programming environments. SCM is at the core of the functionality
> >that we want to build. And we're planning on providing a staged
> >integration scheme, which requires a strong command line. But the
> >ultimate goal is functionality tightly integrated with an IDE.
> >
> >Like the rest of the system, fine-grained functionality is going to
> >be implemented using an extension based architecture. So there'll be
> >a core of fine-grained functionality, which will consist roughly of
> >code to manage the fine-grained artifacts themselves, metadata,
> >aggregation, the aggregate input/output framework, and the
> >analysis/search/retrieval framework.  All of that will be in the core,
> >and will be compilable with the core, from the command-line. Anyone
> >who wants to implement a set of the necessary language components
> >can it, any way they choose: command line, eclipse plugin, whatever.
> >
> >The first fine-grained language components that we're going to write
> >are going to be Java. And they're going to be implemented using the
> >Eclipse java components, and therefore be an Eclipse plugin. There are
> >two good reasons for that:
> >
> >First, as I said before: our goal is to build a better IDE, and since
> >we're using Eclipse as a base platform, we should be doing whatever we
> >reasonably can to make it easy to smoothly integrate our functionality
> >into Eclipse.
> >
> >Second, as I've mentioned lately in some discussions with Jonathan
> >Gossage: to build the kind of functionality that we want, we really need
> >to be integrated into a compiler. We need a full parser and analyzer
> >for any language that we support. We can implement it ourselves, in
> >which case it's our job to keep it up to date, and compatible with the
> >"real" compiler; or we can plug in to a real compiler, and use it.  We
> >simply don't have the resources to build and maintain our own Java
> >parser/analyzer, and keep it in sync with the Eclipse Java compiler.
> >Even if we did have the resources, I don't think it would be a good
> >idea to implement it ourselves; it seems to me like a classic case of
> >where re-use is appropriate.

In fact I believe that it will become necessary to extend the parser and
analyzer to define intermediate node types that are not relevant to the
parser and analyzer but which contain standard Java nodes below them. Such
nodes can provide a general mechanism for tools to recognize and deal with
fine grained artifacts. For example I made some proposals about string
handling today in a separate message. The capability proposed here would
make it easier to deal with the code automation I talked about there.

Incidentally this kind of capability is going to promote the AST maintained
by the parser into a first class structure that will probably need to be
persisted, something that falls well within the Stellation purview.


> >
> >Does this mean it works exclusively inside of Eclipse? Not necessarily.
> >You can structure almost any application as a set of plugins to be
> >started by the Eclipse launcher. That's how the AspectJ folks are
> >implementing the next version of the AspectJ compiler.  There's no
> >reason that you couldn't build a command-line Stellation that way.
> >(Ringo De Smet has proposed doing that as the default way of executing
> >Stellation. If we can figure out how to run the Eclipse Java compiler
> >from ant, I'd probably be in favor of doing that.)
> >
> >But on the other hand, it's my opinion that fine-grained functionality
> >probably won't work particularly well from the command line. The
> >fundamental point of fine-grained SCM is to enable a set of
> >functionality that really requires living inside of an IDE of some sort.
> >
> >Again: none of this obligates you to go along with me. This is
> >open-source, and you're a committer. If you think I'm wrong, you're
> >welcome to try to convince me. I'll be a hard sell, but I *am* open
> >to be convinced. And even if you can't convince me, you're welcome
> >to use the fine-grained framework to build things the way that you
> >think is correct. I'll be extremely careful to always keep the system
> >core completely compatible with both Eclipse plugins and standalone
> >command-lines.
> >
> >	-Mark
> >


Regards

Jonathan

Personal Email
jgossage@xxxxxxxx


Business Email
jonathan@xxxxxxxxxxxxxx