[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

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
>