[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Problems with Building -- Exporting aspects across multiple projects in eclipse
|
Hi Andy,
So, I am able to reproduce the same behavior from the command line. I
don't understand what's going on either. Here are the steps I did:
1 do a full clean build in eclipse, with tests in correct state
2 run tests in eclipse, all pass
3 run tests on command line, with CLASSPATH pointing to eclipse output
folders, all pass
4 introduce an error into one test by changing a string
5 let eclipse do an incremental build (can see only the class with the
string changed gets rebuilt in the trace window)
6 run the javap command, confirm that the incorrect string is in the
expected class file in the expected folder
7 run tests in eclipse, they pass but should not
8 run on command line, tests pass but should not
9 do a full clean build in eclipse
10 javap confirms that the error is still there
11 run tests in eclipse-- get expected error
12 run tests on command line-- get expected error
I too don't see where the old file could be living. Maybe the new
file is not getting updated correctly? I also used javap to search
for the correct and incorrect string-- I only see one at a time, when
I expect to see it (rather that maybe seeing both of them in there).
Any other ideas or things I can test?
Thanks Mike
On Fri, Apr 11, 2008 at 4:36 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
> Are you able to run the testcase outside of eclipse from the command
> line? I can't see where it is getting the old classfile from when
> executing the test if the .class on the disk is correct...
>
>
>
> Andy.
>
> On 11/04/2008, Mike Schneider <mikepschneider@xxxxxxxxx> wrote:
> > The time stamp on the class file is updated. The new string does
> > appear in the class
> > file when I use the javap command. But I still see this behavior.
> >
> > I also tried: disabling inlining of code, and removing the binary
> > output folder of the aspects
> > project from the aspectpath and the classpath of project C. None of
> > those solved the behavior.
> >
> > The only thing that seems to fix it is to remove the aspectj nature of
> > project C. So it seems
> > that when the aspectj nature is on, and the java files are compiled
> > with ajc, that the
> > correct class files are generated, but when I launch they are somehow
> > not picked up by the code
> > that is executing.
> >
> >
> > On Fri, Apr 11, 2008 at 3:21 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
> > > So you can run the test in project C without the aspecpath being set
> > > for the project, if it is just a logging aspect? Does the test pickup
> > > the string change in this case?
> > >
> > > Does the timestamp on file X change on the disk when it is rebuilt?
> > > Can you use javap -verbose on it to check it really has the new string
> > > value in the class file?
> > >
> > > You could try switching off around advice inlining in project C to see
> > > if that makes any difference (in one of the AJDT preference menus) -
> > > it shouldn't... but it is something to try.
> > >
> > >
> > >
> > > Andy.
> > >
> > > On 11/04/2008, Mike Schneider <mikepschneider@xxxxxxxxx> wrote:
> > > > I am not using inpath, only aspectpath.
> > > >
> > > > I changed a string in java file X in project C. The unit test that
> > > > referred to that string also lived in project C. I could see that
> > > > only file X was the one file that got recompiled and rewoven. I did
> > > > not expect any other files to be recompiled and did not see any, only
> > > > file X was recompiled.
> > > >
> > > > The aspect is a simple entry-and-exit logging using an around advice.
> > > > The unit test does not depend on the aspect actually being there to
> > > > pass.
> > > >
> > > > I'll see if I can reproduce it with a sample set of projects.
> > > >
> > > >
> > > >
> > > > On Fri, Apr 11, 2008 at 1:22 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
> > > > > > With all of the event tracing on, when I changed the file and save it,
> > > > > > I see that AJC recompiles and reweaves that one file. It does not
> > > > >
> > > > > > show any obvious errors or other problems. But, when I run the unit
> > > > > > test in eclipse I don't see my change. Only when I do a full rebuild
> > > > > > do I see the changes in the unit test.
> > > > >
> > > > > Which file to do you change? Something in the Aspect project? Project C?
> > > > > Does the change you expect to see in the unit test rely on the aspect being
> > > > > rewoven? The unit test is in which project C?
> > > > > When you make the change and save it, and see it rebuild/reweave - is there
> > > > > a file in a dependent project you would expect to be seeing rebuilt but it
> > > > > does not?
> > > > >
> > > > > This might be easier with a concrete set of test projects that exhibit
> > > > > the problem.
> > > > > Right now I don't know why this would be failing, if the event trace view shows
> > > > > something is rebuilt/rewoven then the new version is on the disk and when
> > > > > executing the tests, that is the version that will be used. Elements on the
> > > > > aspectpath are implicitly included on the classpath for a project as
> > > > > well, I hope
> > > > > that isn't causing you a problem with a type in the aspect project overriding
> > > > > some type from another project. You aren't using inpath anywhere are you?
> > > > >
> > > > >
> > > > >
> > > > > Andy.
> > > > >
> > > > > On 11/04/2008, Mike Schneider <mikepschneider@xxxxxxxxx> wrote:
> > > > > > My projects are set up as such (somewhat simplified, as I really have
> > > > > > 8 eclipse projects, but I'll describe what I believe is relevant)
> > > > > >
> > > > > > Projects Aspects is the base project (and contains only one aspect
> > > > > > file, and no java files)
> > > > > > Project A includes the binary output folder from Project Aspects on
> > > > > > its aspect path
> > > > > > Project B depends on project A, and includes the binary output folder
> > > > > > from Project Aspects on its aspect path
> > > > > > Project C depends on project B, and includes the binary output folder
> > > > > > from Project Aspects on its aspect path
> > > > > >
> > > > > > All 4 projects have aspectj nature turned on.
> > > > > >
> > > > > > I noticed the particular issue below in Project C, but my colleagues
> > > > > > have observed it in other projects (B for instance).
> > > > > >
> > > > > > With all of the event tracing on, when I changed the file and save it,
> > > > > > I see that ACJ recompiles and reweaves that one file. It does not
> > > > > > show any obvious errors or other problems. But, when I run the unit
> > > > > > test in eclipse I don't see my change. Only when I do a full rebuild
> > > > > > do I see the changes in the unit test.
> > > > > >
> > > > > > My version info is as follows:
> > > > > > AJDT Version: 1.5.2.200804031719
> > > > > > AspectJ version: 1.6.0.20081300000000
> > > > > >
> > > > > > Any ideas?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Apr 11, 2008 at 12:44 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
> > > > > > > How are your projects configured? Did you go for aspectpath or inpath?
> > > > > > > So you have AJDT Project A and Java Project B with B depending on A
> > > > > > > via aspectpath ? You make the change where ? to java code in A or B?
> > > > > > >
> > > > > > > Are you on a recent version of AJDT (I made some changes to
> > > > > > > incremental compilation recently).
> > > > > > >
> > > > > > > To understand what is/isnt getting built you can activate the AJDT
> > > > > > > Event Trace view in eclipse, turn on full reporting of all types of
> > > > > > > event (button in top right) and then when you make your change it will
> > > > > > > tell you everything it is doing. Does something in there not look
> > > > > > > right?
> > > > > > >
> > > > > > > Andy.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 11/04/2008, Mike Schneider <mikepschneider@xxxxxxxxx> wrote:
> > > > > > > > Thanks Andy. I basically figured out the same thing after some
> > > > > > > > hunting. This technique works and it shows the correct markers in my
> > > > > > > > code.
> > > > > > > >
> > > > > > > > However, I have a second problem. Now when I run my code within
> > > > > > > > eclipse it does not pick up my recent changes to the java
> > > > > > > > files without doing a clean. For instance, I have a unit test that
> > > > > > > > passes. I update some of the data inputted to the unit test
> > > > > > > > such that it shouldn't pass. I run it again (with build
> > > > > > > > automatically turned on) and it still passes. I do a full clean,
> > > > > > > > allow the
> > > > > > > > rebuild to run, and run it again, and the test fails. The only
> > > > > > > > solution I have currently is to disable aspects, or to do a full clean
> > > > > > > > each time
> > > > > > > > I execute.
> > > > > > > >
> > > > > > > > Any idea what's going on here, and how I can fix it? Thanks
> > > > > > > >
> > > > > > > > Mike
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Apr 7, 2008 at 9:28 AM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
> > > > > > > > > Hello Mike,
> > > > > > > > >
> > > > > > > > > Aspects from a project upon which you depend are not automatically
> > > > > > > > > picked up unless they can be found on the aspect path for the project
> > > > > > > > > you want to get woven.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > I also tried adding the folder
> > > > > > > > > > containing the .aj files to the Inpath of the derived project and the
> > > > > > > > > > AspectJ path of the derived project.
> > > > > > > > >
> > > > > > > > > Like classpath, the inpath and aspectpath are for jars and directories
> > > > > > > > > containing class files, not source files. You need to put the bin
> > > > > > > > > folder of the project where the aspects are built onto the aspectpath
> > > > > > > > > of the projects you want to be woven. ( I know this could be more UI
> > > > > > > > > friendly and involve some simple clicks rather than path
> > > > > > > > > configuration). With the compiled aspects on the aspectpath, the
> > > > > > > > > projects will get woven. Now, showing across project markers is quite
> > > > > > > > > complicated (perhaps I mean 'not always 100% reliable' ....) so the
> > > > > > > > > best way to verify your code is woven as you expect is to run your
> > > > > > > > > tests. Or you could turn on the weave info messages in the UI and
> > > > > > > > > then information about what gets woven will come out in the problems
> > > > > > > > > view as info messages.
> > > > > > > > >
> > > > > > > > > Andy.
> > > > > > > > > _______________________________________________
> > > > > > > > > aspectj-users mailing list
> > > > > > > > > aspectj-users@xxxxxxxxxxx
> > > > > > > > > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > aspectj-users mailing list
> > > > > > > > aspectj-users@xxxxxxxxxxx
> > > > > > > > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > > > > > > >
> > > > > > > _______________________________________________
> > > > > > > aspectj-users mailing list
> > > > > > > aspectj-users@xxxxxxxxxxx
> > > > > > > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > > > > > >
> > > > > > _______________________________________________
> > > > > > aspectj-users mailing list
> > > > > > aspectj-users@xxxxxxxxxxx
> > > > > > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > > > > >
> > > > > _______________________________________________
> > > > > aspectj-users mailing list
> > > > > aspectj-users@xxxxxxxxxxx
> > > > > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > > > >
> > > > _______________________________________________
> > > > aspectj-users mailing list
> > > > aspectj-users@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > > >
> > > _______________________________________________
> > > aspectj-users mailing list
> > > aspectj-users@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
