|
As you can no doubt deduce from
Andy's notes, we've been working hard on getting the new AspectJ stable in AJDT.
In non-incremental I believe we are back to a good base now. Incremental needs a
lot of work across the board and is not going to be anything other than an
experimental feature of AJDT 1.1 - it doesn't seem wise to me to try and make
changes of that magnitude now in Ajde, our emphasis should be on getting the
highest product quality possible on the existing feature set. For me personally,
I would also take that line for the period between 1.1rc2 and 1.1 final. There's
been a lot of good work gone on in the last few days, and I'm certainly not
suggesting we back that out, but I would vote for locking down now and only
commiting changes that are :
* to fix an accepted P1 or P2 bug tracked on
bugzilla,
* to fix a failing test case,
* or, some other worthy cause
discussed and agreed on this list
I nominate Jim as final arbiter on
anything in the last category (though you can always decline that role if you
wish Jim ;-) ),
Chiefly I think this boils down to not putting in
any further changes motivated *solely* by trying to support incremental
compilation from ides.
AJDT is locking down too and will operate in a
similar mode.
Once we get beyond 1.1.0, we should look at fencing the
relevant portions of ajde in with some clearly defined test-cases and
interfaces, and then take a step back and think through the design of ajde to
fully support incremental. For example, currently we have a number of
tests of different kinds in the code to determine which compilation mode we're
in, it would be nice to consolidate those and make the strategies clearer. Then
there's the incremental structure model building, feedback from the compiler as
to which files have actually been compiled, the clearing and raising of the
appropriate task markers in the ide, consequences for the global crosscutting
view etc. to be worked through. That will be plenty enough change to
warrant an independent release to 1.1.0!
George is looking into the test
case failures on ibm 1.3.1 jdk, and my reading of current activity levels
suggests that Friday is probably the earliest we should now shoot for the 1.1rc2
candidate build, with another dry run tomorrow to pick up any overnight
changes.
Anyways, just my two-cents' worth - happy to be
over-ruled!
--
Adrian.
adrian_colyer@xxxxxxxxxx
07 May 2003
06:30
To: aspectj-dev@xxxxxxxxxxx
cc:
From: Wes Isberg
<wes@xxxxxxxxxxxxxx>
Subject: Re: [aspectj-dev] Problems getting
'non-incremental' to work in AJDT
>
Trying to shoe-horn in a new feature during this time is very risky. I
think you need to
> be
prepared to either not release incremental-ajde for 1.1.0 or to make a case on
this
>
list that incremental support in ajde is so important we should significantly
delay
> the
1.1.0 release in order to have time to get it right
I don't think of incremental compilation as a new feature, but I agree that
we
would not get to an incrementally-built structure model in reasonable
time for 1.1.
So I think AJDE (i.e., AJBrowser) must support compiling incrementally
for 1.1, but 1.1 has as known limitations when displaying the structure
model:
- a full rebuild is required to get a valid structure model
-
errors can cause the structure model not to be built.
- urk: a matched
declare error can cause the compile to look like it failed,
but we'd
still like to show the presumably-correct structure model
By those standards, ajbrowser/AJDE should be ready tomorrow.
Also, I'm not sure whether to leave up an old structure model in case of
compile failure. I think that's right when/because it will be more
useful
than disturbing, if we can signal its potential invalidity.
Wes
Jim.Hugunin@xxxxxxxx wrote:
I'm going to check in a different
change that creates a new AjState object
whenever doing a batch build.I can be
much more confident that this will be like restarting the compiler - which is
the desired behavior for this case.This
will also address the concerns you have in your other message about implicit
initialization assumptions in this
class.
The only testing that I've done
for incremental compilation is based on the command-line compiler where the
only way to do a full re-build after the first build is by ending the process
and starting the compiler again. So, I'm not too surprised that there are
issues using the compiler in this way from ajde.
Note: Incremental compilation is
hard.It took a couple of months to
implement correctly for the compiler and the weaver - and I'm still confident
that bugs remain to be found.I wouldn't
be surprised if incremental structure building turns out to be hard as
well.
There are currently 6 unit tests
failing in ajde under IBM JDK1.3.1. These are the sorts of failures that we're
supposed to be addressing between the preview build and a final release.Trying to shoe-horn in a new feature during
this time is very risky.I think you
need to be prepared to either not release incremental-ajde for 1.1.0 or to make a case on this list that
incremental support in ajde is so important we
should significantly delay the 1.1.0 release in order to have time to get it
right.
My two cents -
Jim
-----Original
Message----- From: Andrew Clement [ mailto:CLEMAS@xxxxxxxxxx]
Sent: Tuesday, May 06, 2003 7:15 AM
To: aspectj-dev@xxxxxxxxxxx Subject: [aspectj-dev] Problems getting
'non-incremental' to work in AJDT
After rebuilding AJDT on last nights changes to aspectj, I couldn't
get non-incremental to work properly - it would be OK for the first compile
within eclipse, but subsequent compiles always appeared to be non-full builds,
despite the fact that I was always calling buildFresh. If I restarted
eclipse, my first compile would always be OK.
I eventually traced it to
AjState.prepareForNextBuild() - this function returns false if a batch build
must be done. Returns true if an incremental build *could* be
done. I extended the method to take an extra parameter (batch) and put
the line in that checks for the batch setting. I've attached the changed
version below.
The problem with the original version of this
method seems to be that on the second compilation, it gets past the 'if
(lastSuccessfulBuildTime==-1 || buildConfig == null)' and starts modifying
some fields of AjState - in particular it appears the 'simpleStrings' field
that it changes is used elsewhere in the class - (see writeClassFile in
AjState). With my guard for the batch setting, we don't change these
fields. I don't think this is quite the right fix - as it forces
prepareForNextBuild to return false whenever batch is in operation - but it is
sufficient to get us to progress. AJDT is looking much more
healthy.
/**
*Returnsfalseifabatchbuildisneeded.
*/
boolean
prepareForNextBuild(AjBuildConfig newBuildConfig,boolean batch) {
currentBuildTime = System.currentTimeMillis();
addedClassFiles = new ArrayList();
// Next line added by Andy
if (batch) returnfalse;
if (lastSuccessfulBuildTime
== -1 || buildConfig == null) {
returnfalse;
}
simpleStrings = new ArrayList();
qualifiedStrings = new ArrayList();
Set oldFiles = new
HashSet(buildConfig.getFiles());
Set newFiles = new
HashSet(newBuildConfig.getFiles());
addedFiles = new HashSet(newFiles);
addedFiles.removeAll(oldFiles);
deletedFiles = new HashSet(oldFiles);
deletedFiles.removeAll(newFiles);
this.newBuildConfig =
newBuildConfig;
returntrue;
}
cheers,
Andy.
clemas@xxxxxxxxxxxxxxx _______________________________________________
aspectj-dev mailing list aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev
|
