[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] can't compile anymore with generic in pointcut
|
On this bit:
> Sorry for the confusion but I only installed AJDT via Eclipse
update - so I thought it got some AspectJ by
> itself. To my surprise,
the AspectJ JAR offered as separate download on the AJDT site (the
AspectJ site
> says nothing about 1.6.4) DOES contain aspectjtools.jar.
How come then my Eclipse was missing it???
> For that matter, I was
missing aspectjweaver and the matcher as well (which might explain why
once
> JDT weaving enabled everything started to break, but I will come
again with that later)
The aspectj compiler for command line (and Ant) usage contains 4 jars.
aspectjrt.jar - the runtime
org.aspectj.matcher.jar - the matcher code and the runtime
aspectjweaver.jar - the weaver, the matcher code and the runtime
aspectjtools.jar - the modified JDT compiler, the compiler dependencies, the weaver, the matcher code and the runtime
This overlap where each includes a copy of what is in the previous one is historical, not for any other reason than that using aspectjtools.jar means you don't need anything else. The aspectjweaver.jar is all you need if doing load time weaving.
In AJDT the aspectjtools.jar is broken into entirely separate pieces:
org.aspectj.runtime - the runtime
org.aspectj.weaver - the weaver
org.aspectj.ajde - the compiler (the compiler dependencies from aspectjtools are discarded since they are satisfied by the eclipse plugins, reducing the AJDT download size a bit)
aspectjtools.jar is decomposed to build these three plugins. aspectjtools.jar is not part of AJDT. If you want to use just what is in AJDT to drive aspectj Ant builds and you don't want to download the command line compiler for some reason, you need to follow
http://www.eclipse.org/ajdt/faq.php#q:ant - which describes the constituent set of plugin jars that reconstructs what was in aspectjtools.jar (although that faq entry looks like it might be out of date for recent eclipses...). I took the decision not to include a copy of the command line compiler in an AJDT distribution as it would double the download size of AJDT.
Until recently we simply let you download a recent AspectJ build and that would typically roughly match the compiler in AJDT that included a dev build of AspectJ. Some users don't like that word 'roughly' and wanted the precise version and so now when a release of AJDT is made the precise AspectJ dev build that it includes is made available separately and permanently. AJDT 1.6.4 is the first release to do this.
Andy.
2009/3/20 Justin Case
<send_lotsa_spam_here@xxxxxxxxx>
--- On Fri, 3/20/09, Andy Clement wrote:
> I'd raise a bug for that - and
> attach more code to the bug if you can, I don't think I
> have enough to go on from the message with all those
> generics flying around - what pointcut are you matching
> with? what is the joinpoint you are matching on?
At the end of this message there are the relevant snippets, I'll save them in the bug as well if you confirm I should.
> Err, AJDT doesn't ship aspectjtools.jar. That is
> available as part of the corresponding AspectJ
> distribution.
Sorry for the confusion but I only installed AJDT via Eclipse update - so I thought it got some AspectJ by itself. To my surprise, the AspectJ JAR offered as separate download on the AJDT site (the AspectJ site says nothing about 1.6.4) DOES contain aspectjtools.jar. How come then my Eclipse was missing it??? For that matter, I was missing aspectjweaver and the matcher as well (which might explain why once JDT weaving enabled everything started to break, but I will come again with that later)
Thanks a lot,
JM
...and here the aspect code:
pointcut syncFields( DataStorage theData, HashMap<String, FieldModel<?>> changedMap, HashMap<String, FieldModel<?>> outputMap, boolean runRules ) : call (private * com.myapp.model.DataStorage.syncFieldChanges(..))
&& target(theData)
&& args(changedMap, outputMap, runRules)
&& !within(DataAccess);
void around( DataStorage theData, HashMap<String, FieldModel<?>> changedMap, HashMap<String, FieldModel<?>> outputMap, boolean runRules ) throws DataModellException
: syncFields(theData, changedMap, outputMap, runRules)
{
...
}
...and the java:
private void syncFieldChanges( HashMap<String, FieldModel<?>> changedMap, HashMap<String, FieldModel<?>> outputMap, boolean runRules ) throws DataModelException
{
throw new DataModelException( "Never supposed to go through syncFieldChanges!" );
