Fwd: [ajdt-dev] Question about the AJDT weaver

[Andrew Eisenberg <andrew@xxxxxxxxxxxx>]

Should have sent this to the list.


---------- Forwarded message ----------
From: Andrew Eisenberg <andrew@xxxxxxxxxxxx>
Date: Thu, Apr 22, 2010 at 9:37 AM
Subject: Re: [ajdt-dev] Question about the AJDT weaver
To: Raffi Khatchadourian <khatchad@xxxxxxxxxxxxxxxxxx>


Invoking a build is like this:

ResourcesPlugin.getWorkspace().build(IncrementalProjectBuilder.INCREMENTAL_BUILD,
new NullProgressMonitor());

But, remember, this invokes a build of what is on disk already.  The
build above is incremental.  If you want a full build, use
IncrementalProjectBuilder.FULL_BUILD instead.

There is plenty of JDT infrastructure that we already hook into in
order to ITD-aware reconciling of Java and AJ files.  For example,
look at AJCompilationUnitProblemFinder.  This class takes the results
of a JDT reconcile and applies it to an AJ file.  It removes any
errors that come from AJ syntax, but are actually correct.  This is a
bit of a kludge.  A much better solution would be to invoke an AJC
reconcile and get more precise results back, including a crosscutting
model.

The main problem is that the AJC and AJDT infrastructure is not there
yet to get this working as you type.  Yes, there are a lot of open
questions on this.

On Thu, Apr 22, 2010 at 7:48 AM, Raffi Khatchadourian
<khatchad@xxxxxxxxxxxxxxxxxx> wrote:
> Hi Andrew,
>
> Bug 242589 is exactly what I am talking about. In particular, this statement sums it up:
>
>> matcher code can be backed by an Eclipse JDT model of resources rather than
>> reflection
>>
>> This (above) case will enable much neater matching in Eclipse and even sets up
>> the possibility of showing matches *as you type*
>
> Right now, matches don't show up until the file is saved. IMO, this is analogous to the situation where Java compilation errors don't show up until the java file is saved. It sounds like a bit of work, however (as you mentioned below). Would there be an appropriate first action to kick this off? Or, is there something in the JDT that has similar functionality that we could benefit from studying? Yes, I agree that a project with a large number of pieces of advice may be difficult to edit. Perhaps there could be some threshold value that controls the number of aspects that are matched on-the-fly, or perhaps even some sort of optimization techniques.
>
> Hm, sounds like an interesting research topic! :)
>
> Also, if you don't mind, could you point me in the right direction to programmatically invoke the building process? I would greatly appreciate it, and thanks again for your help!
>
> Raffi
>
> On Apr 21, 2010, at 6:01 PM, Andrew Eisenberg wrote:
>
>> Yes, this is definitely possible and it may be able to be implemented
>> efficiently.  AspectJ does expose the proper API for this:
>> https://bugs.eclipse.org/242589
>>
>> However, there is much that would need to be done for AJDT.  I can
>> raise a bug for this, but honestly, without some help this is unlikely
>> to be done in the near future.
>>
>> I do see some big potential problems with this, however.  Editing an
>> aspect that temporarily matches a large number of elements could cause
>> problems.  Similarly, a project with a large number of aspects (as is
>> common for Roo projects) may also be difficult to edit.
>>
>>
>> On Wed, Apr 21, 2010 at 2:28 PM, Raffi Khatchadourian
>> <khatchad@xxxxxxxxxxxxxxxxxx> wrote:
>>> Hi Andrew,
>>>
>>> I have been giving this some more thought, and I don't know how inefficient on-the-fly matching would actually be. The reason is that we would only need to consider a local change. Therefore, the complexity of the problem would be dependent on the number of pointcuts available in the system. In other words, we don't have to consider the entire base-code, just the base-code that has been altered. Then, we match this new base-code with all available pointcuts. What do you think?
>>>
>>> Raffi
>>>
>>> On Apr 20, 2010, at 12:29 AM, Andrew Eisenberg wrote:
>>>
>>>> What you are talking about is an operation called reconciling.  This
>>>> operation calls the compiler just to get the structure of a file and
>>>> any compile problems, but doesn't produce byte code.  This happens in
>>>> aj files as well as Java files, but the reconciling does not perform
>>>> any weaving.  In theory, ajc can do weaving on the fly (the analog
>>>> operation to reconciling in this case would be called matching), but
>>>> this is not implemented in AJDT.  It would be difficult to ensure that
>>>> performance is maintained as the matching occurs.
>>>>
>>>> To answer another question, yes, you can perform a build without doing
>>>> a save, but the build will not include the unsaved parts of your
>>>> files.  This is quite different from reconciling, though.
>>>>
>>>> Let me know if you need any code snippets.
>>>>
>>>> On Mon, Apr 19, 2010 at 4:35 PM, Raffi Khatchadourian
>>>> <khatchad@xxxxxxxxxxxxxxxxxx> wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> Thank you for the prompt response. I suppose my question is as follows. Is it possible to trigger a build without saving all files? That question may be more general to Eclipse, but I find it curious that the JDT parses Java files even if they are not saved, but the AJDT does not weave files if all changes are not saved. Thanks again!
>>>>>
>>>>> Raffi
>>>>>
>>>>> On Apr 19, 2010, at 5:28 PM, Andrew Eisenberg wrote:
>>>>>
>>>>>> I'm not exactly sure what you are asking.  Yes, the weaver only runs
>>>>>> when a build is triggered.  This typically happens when files are
>>>>>> saved.
>>>>>>
>>>>>> Are you asking about how files that have join points targeted by the
>>>>>> aspects change when an aspect changes?  This logic is coded into the
>>>>>> state stored by AspectJ, which knows about aspect dependencies.  In
>>>>>> most cases, a change and subsequent compile of an aspect will also
>>>>>> trigger a compile of these dependent files.
>>>>>>
>>>>>> Not sure if this answers your question...
>>>>>>
>>>>>> On Mon, Apr 19, 2010 at 1:33 PM, Raffi Khatchadourian
>>>>>> <khatchad@xxxxxxxxxxxxxxxxxx> wrote:
>>>>>>> Hello. I am using Eclipse Build id: 20100218-1602 and AJDT version 2.0.2.e35x-20100105-0900. I have noticed that the weaver only performs the weaving process when a particular file is saved, as opposed to when it is changed. Is this correct and, if so, how do I get the AJDT weaver to weave aspects into the base-code when a particular change is made in the base-code. Thank you in advance for your help, and please inform me if this is not the correct forum for this question.
>>>>>>>
>>>>>>> Raffi Khatchadourian
>>>>>>> PhD Candidate
>>>>>>> Department of Computer Science and Engineering
>>>>>>> Ohio State University
>>>>>>> http://www.cse.ohio-state.edu/~khatchad
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> ajdt-dev mailing list
>>>>>>> ajdt-dev@xxxxxxxxxxx
>>>>>>> https://dev.eclipse.org/mailman/listinfo/ajdt-dev
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>