Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » AspectJ » inter-project dependencies
inter-project dependencies [message #24393] Tue, 05 August 2003 04:14
Wes Isberg is currently offline Wes IsbergFriend
Messages: 8
Registered: July 2009
Junior Member
Currently for aspects to affect code from another project, one can

(a) symbolically link into the current project the source files from the
other project (and add all required dependencies) (Ron's solution, per
Adrian)

(b) after Mik fixes the ../../ bug, perhaps refer directly to files from
another project in a .lst file;

(c) add ant as an external builder to zip up the result of the source
projects and include them in the -injars specified for the aspect
project. For task window messages to navigate to the sources, the
source projects must be in the project dependencies. Also, you'll have
to rebuild manually when those change.

....

I'm sure you-all have talked about how to make this easier. What I'd
like to see is a tabbed pane in the Java Build Path properties that
permits one to specify that a particular project or library is to be
included on the classpath, injars, or aspectpath. (This could replace
by supersetting the order and export tabbed pane, or perhaps this could
replace the current implementation of the AspectJ compiler properties
page/pane associated with a project.)

What would one do in the AJDT tree to implement the property pane?

One way (read: hack) to drive the options through to ajc is by including
the options in a .lst file, and having the code that combines the
various project properties extract entries listed on the aspectpath or
injars from the classpath. This would provide a default implementation
for any IDE integration that puts things on the classpath for extraction
later (I'm thinking JSP compiles and other IDE or Ant integrations
here). AspectJ/AJDE would implement the option merging (which we do for
other options anyway), so IDE integrations could annotate the classpath
without having to edit it. Indeed, I can imagine permitting the .lst
files to specify only the filenames, with actual paths extracted from
the classpath, and/or supporting the convention that a sourceroot
containing a file "aspectj-options.lst" will cause the
"aspectj-options.lst" to be read. So many hacks, so little time...

Which brings up another point about configuration (.lst) files. I'd
like to see the general options for an AspectJ project persisted in a
aspectj-options.lst file at the base of the project, with references
thereto by various .lst files generated in the project (typically
listing source file subsets, the default one being default.lst, which
lists @aspectj-options.lst and source directories as sourceroots).

This has the nice property that it's portable and testable: one can run
without Eclipse and compare the results of compiling from the
command-line with the results from compiling within Eclipse. It is also
a useful way to distinguish AspectJ and AJDT bugs; if it failed from the
command-line, it would be an AspectJ bug. (On that note: there's an
AJDE adapter for the ajc compiler tests; you might consider writing one
for AJDT, so you can run the compiler tests programmatically...) This
also suggests that it's the job of AspectJ/AJDE to provide some
framework for manipulating .lst files, which could be surfaced in
IDE-specific editors.

So...

Are there better approaches or implementations?

Is anyone planning to work on this, or willing to help a contributor do so?

Thanks -
Wes
Previous Topic:Aspect files are not visible in Java Browsing perspective
Next Topic:inter-project dependencies
Goto Forum:
  


Current Time: Tue Mar 19 03:41:25 GMT 2024

Powered by FUDForum. Page generated in 0.01875 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top