| 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. 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 -- Mark Craig Chu-Carroll, IBM T.J. Watson Research Center *** The Stellation project: Advanced SCM for Collaboration *** http://www.eclipse.org/stellation *** Work Email: mcc@xxxxxxxxxxxxxx ------- Personal Email: markcc@xxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part